Re: ftrace/kprobes: Warning when insmod two modules
(2014/03/24 23:59), Steven Rostedt wrote:
> On Mon, 24 Mar 2014 20:26:05 +0900
> Masami Hiramatsu wrote:
>
>
>> Thank you for reporting with this pretty backtrace :)
>> Steven, I think this is not the kprobe bug but ftrace (and perhaps, module).
>
> Looks to be more of a module issue than a ftrace issue.
>
>>
>> If the ftrace can set loading module text read only before the module
>> subsystem
>> expected, I think it should be protected by the module subsystem itself
>> (e.g. set_all_modules_text_ro(rw) skips the modules which is
>> MODULE_STATE_COMING)
>>
>
> Does this patch fix it?
Yep, I tested using my reproducer and confirmed that this patch fixed
this issue, thanks!
Thanks,
Takao Indoh
>
> In-review-off-by: Steven Rostedt
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 5a50539..a1acabf 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -207,10 +207,11 @@ struct module_use {
> };
>
> enum module_state {
> - MODULE_STATE_LIVE, /* Normal state. */
> - MODULE_STATE_COMING,/* Full formed, running module_init. */
> - MODULE_STATE_GOING, /* Going away. */
> - MODULE_STATE_UNFORMED, /* Still setting it up. */
> + MODULE_STATE_LIVE, /* Normal state. */
> + MODULE_STATE_COMING,/* Full formed, running module_init. */
> + MODULE_STATE_COMING_FINAL, /* Ready to be changed to read only. */
> + MODULE_STATE_GOING, /* Going away. */
> + MODULE_STATE_UNFORMED, /* Still setting it up. */
> };
>
> /**
> diff --git a/kernel/module.c b/kernel/module.c
> index d24fcf2..0905bed 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -1805,7 +1805,8 @@ void set_all_modules_text_ro(void)
>
> mutex_lock(_mutex);
> list_for_each_entry_rcu(mod, , list) {
> - if (mod->state == MODULE_STATE_UNFORMED)
> + if (mod->state == MODULE_STATE_UNFORMED ||
> + mod->state == MODULE_STATE_COMING)
> continue;
> if ((mod->module_core) && (mod->core_text_size)) {
> set_page_attributes(mod->module_core,
> @@ -3020,6 +3021,13 @@ static int do_init_module(struct module *mod)
> blocking_notifier_call_chain(_notify_list,
> MODULE_STATE_COMING, mod);
>
> + /*
> + * This module must not be changed by set_all_modules_text_ro()
> + * until we get here. Otherwise notifiers that change text
> + * (like ftrace does) will break.
> + */
> + mod->state = MODULE_STATE_COMING_FINAL;
> +
> /* Set RO and NX regions for core */
> set_section_ro_nx(mod->module_core,
> mod->core_text_size,
>
>
>
--
印藤隆夫(INDOH Takao)
E-Mail : indou.ta...@jp.fujitsu.com
TEL: 7551-4832(055-924-7241)
富士通(株) PFソ事本)Linux開発統括部 開発部
--
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] uio: fix vma io range check in mmap
the vma range size is always page size aligned in mmap, while the real io space range may not be page aligned, thus leading to range check failure in the uio_mmap_physical(). for example, in a case of io range size "mem->size == 1KB", and we have (vma->vm_end - vma->vm_start) == 4KB, due to "len" is aligned to page size in do_mmap_pgoff(). now fix this issue by align mem->size to page size in the check. Signed-off-by: Bin Wang --- drivers/uio/uio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c index a673e5b..e371f5a 100644 --- a/drivers/uio/uio.c +++ b/drivers/uio/uio.c @@ -655,7 +655,7 @@ static int uio_mmap_physical(struct vm_area_struct *vma) if (mem->addr & ~PAGE_MASK) return -ENODEV; - if (vma->vm_end - vma->vm_start > mem->size) + if (vma->vm_end - vma->vm_start > PAGE_ALIGN(mem->size)) return -EINVAL; vma->vm_ops = _physical_vm_ops; -- 1.7.0.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 net-next 4/7] qlcnic: Remove casts of pointer to same type
> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Tuesday, March 25, 2014 1:46 AM
> To: netdev
> Cc: Shahed Shaikh; Dept-HSG Linux NIC Dev; linux-kernel
> Subject: [PATCH net-next 4/7] qlcnic: Remove casts of pointer to same type
>
> Casting a pointer to a pointer of the same type is pointless, so remove these
> unnecessary casts.
>
> Done via coccinelle script:
>
> $ cat typecast_2.cocci
> @@
> type T;
> T *foo;
> @@
>
> - (T *)foo
> + foo
>
> Signed-off-by: Joe Perches
Acked-by: Shahed Shaikh
Thanks,
Shahed
> ---
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
> b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
> index ec399b7..2d91975 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
> @@ -1388,7 +1388,7 @@ static int qlcnic_83xx_copy_fw_file(struct
> qlcnic_adapter *adapter)
> addr = (u64)dest;
>
> ret = qlcnic_83xx_ms_mem_write128(adapter, addr,
> - (u32 *)p_cache, size / 16);
> + p_cache, size / 16);
> if (ret) {
> dev_err(>pdev->dev, "MS memory write
> failed\n");
> release_firmware(fw);
> --
> 1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL rcu/next] Additional RCU commit for 3.15
* Paul E. McKenney wrote: > Hello, Ingo, > > And, if you are willing to take it, one late-breaking commit. This one > was requested for 3.15 by Peter Zijlstra. [...] No objections at all, looks like a useful facility! > [...] It is low risk because it adds a new in-kernel API with > minimal changes to the existing code. Those minimal changes are the > addition of memory barriers and ACCESS_ONCE() macro calls, neither > of which should be able to break things. This commit has passed > significant rcutorture testing, with these additional additions to > rcutorture slated for 3.16. This commit has also been exposed to > -next testing. > > This change is available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next > > for you to fetch changes up to 765a3f4fed708ae429ee095914a7897acb3a65bd: > > rcu: Provide grace-period piggybacking API (2014-03-20 17:12:25 -0700) > > > Paul E. McKenney (1): > rcu: Provide grace-period piggybacking API > > include/linux/rcutiny.h | 10 > include/linux/rcutree.h | 2 ++ > kernel/rcu/tree.c | 62 > + > 3 files changed, 70 insertions(+), 4 deletions(-) Pulled, thanks a lot Paul! 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: [PATCH 1/2] nohz: use seqlock to avoid race on idle time stats
On 03/24/2014 01:51 PM, Hidetoshi Seto wrote: > (2014/03/24 16:45), Preeti Murthy wrote: >> Hi Hidetoshi, >> >> The patch looks good to me except the comments around the monotonicity >> of the return value of the idle stats observer. I am unable to relate them >> to the dependency on nr_iowait_cpu. >> >> I see that when the reader queries for the idle stats and calls >> get_cpu_idle_time_us(), the nr_iowait_cpu might be 0. When he later >> queries get_cpu_iowait_time_us(), it may be >0 . Hence we will be >> accounting for the idle time in both idle time and iowait time. This >> is definitely a problem. But I do not understand what this has got to >> do with the monotonicity of the time >> returned. This is just for my understanding. > > Thank you for your comment! > > Ah yes, I think I could write better comments around here to clarify > the monotonicity problem. (It will be happy if someone can give me > such better sentence for here :-D) > > One important point is that readers do not update idle stats when they > use these function. i.e. > > given: >idle stats: idle=1000, iowait=100 >stamp at idle entry: entry=50 >nr tasks waiting io: nr_iowait=1 > > 1st reader: >query @ now=60 > idle=1000 > iowait=110 (=100+(60-50)) > > (here nr_iowait changed to 0) > > 2nd reader: >query @ now=70 > idle=1020 (=1000+(70-50)) > iowait=100 > > So you will see iowait is decreased from 110 to 100. Ah ok! I get it. Please do add my Reviewed-by to it. > > I hope this short story helps you. Thanks! Regards Preeti U Murthy > > Thanks, > H.Seto > -- 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 v0 01/15] drivers: clk: st: Support for DIVMUX and PreDiv Clocks
Quoting Gabriel FERNANDEZ (2014-02-27 07:24:14) > +/** > + * DOC: Clock mux with a programmable divider on each of its three inputs. > + * The mux has an input setting which effectively gates its output. > + * > + * Traits of this clock: > + * prepare - clk_(un)prepare only ensures parent is (un)prepared Minor nitpick but it doesn't look like .prepare or .unprepare are supported below. It looks like this copy/paste comment applies to most of the clk patches as well. It's a small problem and doesn't require a patch respin. But perhaps can be cleaned up some day in the future. Do you want me to take these patches directly or are you just looking for an Ack? Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
Hi, Sandeep Gopalpet I am a developer. Now I confronted an interesting phenomena. When I used linux kernel 2.6.34.15 on freescale-p2020, I can not receive raw and vlan packets on gfar-enet nic. But with e1000e nic, we can make vlan and raw packets work well. I looked into the source code and find that maybe it is related with hardware insert and remove vlan head. But I have no the specifications of gfar-enet nic. Would you like to give some document or some guides? Thanks a lot. Zhu Yanjun The steps are as below. 1. I boot two freescale-p2020 boards with linux kernel 2.6.34.15, then I connected 2 gfar-enet nic cards with a direct network line; 2. On board 1, I checked the driver of eth0 ethtool -i eth0 driver: gfar-enet version: 1.3 firmware-version: N/A bus-info: N/A On board 2, I checked the driver of eth1 ethtool -i eth1 driver: gfar-enet version: 1.3 firmware-version: N/A bus-info: N/A 3. Then I configure the ip address on the above 2 nic cards. On board 1, ifconfig eth0 192.168.1.13/24 up On board 2, ifconfig eth1 192.168.1.196/24 up 4. We can access the other board on one board. For example, on board 1, we can ping board 2. root@p2020rdb:/root> ping 192.168.1.196 PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data. 64 bytes from 192.168.1.196: icmp_req=1 ttl=64 time=2.92 ms 64 bytes from 192.168.1.196: icmp_req=2 ttl=64 time=0.096 ms 5. We configure vlan on these 2 boards. On board 1, modprobe 8021q vconfig add eth0 4091 ifconfig eth0.4091 10.1.1.13/24 up On board 2, modprobe 8021q vconfig add eth1 4091 ifconfig eth1.4091 10.1.1.196/24 up 6. We can access the other board on one board through vlan. For example, on board 1, we can ping board 2 through vlan nic. root@p2020rdb:/root> ping 10.1.1.196 PING 10.1.1.196 (10.1.1.196) 56(84) bytes of data. 64 bytes from 10.1.1.196: icmp_req=1 ttl=64 time=2.92 ms 64 bytes from 10.1.1.196: icmp_req=2 ttl=64 time=0.096 ms But we can not access the other board on one board through raw nic. For example, on board, we can not ping board 2. root@p2020rdb:/root> ping 192.168.1.196 From 192.168.1.196 icmp_seq=1 Destination Host Unreachable From 192.168.1.196 icmp_seq=2 Destination Host Unreachable From 192.168.1.196 icmp_seq=3 Destination Host Unreachable -- 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] staging: comedi: s626: use comedi_timeout() on remaining loops
There were just a handful of more while loops in this file that need timeouts,
and this patch takes care of them, using comedi_timeout(). A couple of new
callbacks are introduced, but there was one case where the appropriate callback
function was already defined; in this case I have just used that.
Signed-off-by: Chase Southwood
---
drivers/staging/comedi/drivers/s626.c | 66 ++-
1 file changed, 58 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/comedi/drivers/s626.c
b/drivers/staging/comedi/drivers/s626.c
index 95fadf3..4dc5659 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -295,10 +295,24 @@ static void s626_debi_replace(struct comedi_device *dev,
unsigned int addr,
/* ** EEPROM ACCESS FUNCTIONS ** */
+static int s626_i2c_handshake_eoc(struct comedi_device *dev,
+struct comedi_subdevice *s,
+struct comedi_insn *insn,
+unsigned long context)
+{
+ unsigned int status;
+
+ status = s626_mc_test(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
+ if (status)
+ return 0;
+ return -EBUSY;
+}
+
static uint32_t s626_i2c_handshake(struct comedi_device *dev, uint32_t val)
{
struct s626_private *devpriv = dev->private;
unsigned int ctrl;
+ uint32_t ret;
/* Write I2C command to I2C Transfer Control shadow register */
writel(val, devpriv->mmio + S626_P_I2CCTRL);
@@ -308,8 +322,9 @@ static uint32_t s626_i2c_handshake(struct comedi_device
*dev, uint32_t val)
* wait for upload confirmation.
*/
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
- while (!s626_mc_test(dev, S626_MC2_UPLD_IIC, S626_P_MC2))
- ;
+ ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc, 0);
+ if (ret)
+ return ret;
/* Wait until I2C bus transfer is finished or an error occurs */
do {
@@ -2029,8 +2044,9 @@ static int s626_ai_insn_read(struct comedi_device *dev,
/* Wait for the data to arrive in FB BUFFER 1 register. */
/* Wait for ADC done */
- while (!(readl(devpriv->mmio + S626_P_PSR) & S626_PSR_GPIO2))
- ;
+ ret = comedi_timeout(dev, s, insn, s626_ai_eoc, 0);
+ if (ret)
+ return ret;
/* Fetch ADC data from audio interface's input shift register. */
@@ -2641,6 +2657,36 @@ static int s626_allocate_dma_buffers(struct
comedi_device *dev)
return 0;
}
+enum {
+ s626_initialize_wait_i2c_abort,
+ s626_initialize_wait_i2c_err_reset
+};
+
+static int s626_initialize_eoc(struct comedi_device *dev,
+ struct comedi_subdevice *s,
+ struct comedi_insn *insn,
+ unsigned long context)
+{
+ struct s626_private *devpriv = dev->private;
+ unsigned int status;
+
+ switch (context) {
+ case s626_initialize_wait_i2c_abort:
+ status = readl(devpriv->mmio + S626_P_MC2);
+ if (status & S626_MC2_UPLD_IIC)
+ return 0;
+ break;
+ case s626_initialize_wait_i2c_err_reset:
+ status = s626_mc_test(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
+ if (status)
+ return 0;
+ break;
+ default:
+ return -EINVAL;
+ }
+ return -EBUSY;
+}
+
static int s626_initialize(struct comedi_device *dev)
{
struct s626_private *devpriv = dev->private;
@@ -2681,8 +2727,10 @@ static int s626_initialize(struct comedi_device *dev)
writel(S626_I2C_CLKSEL | S626_I2C_ABORT,
devpriv->mmio + S626_P_I2CSTAT);
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
- while (!(readl(devpriv->mmio + S626_P_MC2) & S626_MC2_UPLD_IIC))
- ;
+ ret = comedi_timeout(dev, NULL, NULL, s626_initialize_eoc,
+s626_initialize_wait_i2c_abort);
+ if (ret)
+ return ret;
/*
* Per SAA7146 data sheet, write to STATUS
@@ -2691,8 +2739,10 @@ static int s626_initialize(struct comedi_device *dev)
for (i = 0; i < 2; i++) {
writel(S626_I2C_CLKSEL, devpriv->mmio + S626_P_I2CSTAT);
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
- while (!s626_mc_test(dev, S626_MC2_UPLD_IIC, S626_P_MC2))
- ;
+ ret = comedi_timeout(dev, NULL, NULL, s626_initialize_eoc,
+s626_initialize_wait_i2c_err_reset);
+ if (ret)
+ return ret;
}
/*
--
1.8.5.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
[PATCH] [media] uvcvideo: Fix marking buffer erroneous in case of FID toggling
Set error bit for incomplete buffers when end of buffer is detected by
FID toggling (for example when last transaction with EOF is lost).
This prevents passing incomplete buffers to the userspace.
Signed-off-by: Anton Leontiev
---
drivers/media/usb/uvc/uvc_video.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index 8d52baf..57c9a4b 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1133,6 +1133,17 @@ static int uvc_video_encode_data(struct uvc_streaming
*stream,
*/
/*
+ * Set error flag for incomplete buffer.
+ */
+static void uvc_buffer_check_bytesused(const struct uvc_streaming *const
stream,
+ struct uvc_buffer *const buf)
+{
+ if (buf->length != buf->bytesused &&
+ !(stream->cur_format->flags & UVC_FMT_FLAG_COMPRESSED))
+ buf->error = 1;
+}
+
+/*
* Completion handler for video URBs.
*/
static void uvc_video_decode_isoc(struct urb *urb, struct uvc_streaming
*stream,
@@ -1156,9 +1167,11 @@ static void uvc_video_decode_isoc(struct urb *urb,
struct uvc_streaming *stream,
do {
ret = uvc_video_decode_start(stream, buf, mem,
urb->iso_frame_desc[i].actual_length);
- if (ret == -EAGAIN)
+ if (ret == -EAGAIN) {
+ uvc_buffer_check_bytesused(stream, buf);
buf = uvc_queue_next_buffer(>queue,
buf);
+ }
} while (ret == -EAGAIN);
if (ret < 0)
@@ -1173,11 +1186,7 @@ static void uvc_video_decode_isoc(struct urb *urb,
struct uvc_streaming *stream,
urb->iso_frame_desc[i].actual_length);
if (buf->state == UVC_BUF_STATE_READY) {
- if (buf->length != buf->bytesused &&
- !(stream->cur_format->flags &
- UVC_FMT_FLAG_COMPRESSED))
- buf->error = 1;
-
+ uvc_buffer_check_bytesused(stream, buf);
buf = uvc_queue_next_buffer(>queue, buf);
}
}
--
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: linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell
Date: Tue, 25 Mar 2014 13:04:47 +1100
> Today's linux-next merge of the net-next tree got a conflict in
> net/core/netpoll.c between commit c27f0872a344 ("netpoll: fix the skb
> check in pkt_is_ns") from the net tree and commit 9c62a68d1311 ("netpoll:
> Remove dead packet receive code (CONFIG_NETPOLL_TRAP)") from the net-next
> tree.
>
> I fixed it up (the latter removes the code fixed by the former, so I did
> that) and can carry the fix as necessary (no action is required).
That's a perfect resolution, 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] intel_pstate: Use del_timer_sync in intel_pstate_cpu_stop
On Mon, Mar 24, 2014 at 8:11 PM, wrote:
> From: Dirk Brandewie
>
> Ensure that no timer callback is running since we are about to free
> the timer structure. We cannot guarantee that the call back is called
> on the CPU where the timer is running.
>
> Reported-by: Thomas Gleixner
> Signed-off-by: Dirk Brandewie
> Cc: Thomas Gleixner
> Cc: "Rafael J. Wysocki"
> Cc: cpufreq
> ---
> drivers/cpufreq/intel_pstate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index e9092fd..a4a9ba5 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -780,7 +780,7 @@ static int intel_pstate_cpu_stop(struct cpufreq_policy
> *policy)
>
> pr_info("intel_pstate CPU %d exiting\n", cpu_num);
>
> - del_timer(_cpu_data[cpu_num]->timer);
> + del_timer_sync(_cpu_data[cpu_num]->timer);
> intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate);
> kfree(all_cpu_data[cpu_num]);
> all_cpu_data[cpu_num] = NULL;
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL rcu/next] Additional RCU commit for 3.15
Hello, Ingo, And, if you are willing to take it, one late-breaking commit. This one was requested for 3.15 by Peter Zijlstra. It is low risk because it adds a new in-kernel API with minimal changes to the existing code. Those minimal changes are the addition of memory barriers and ACCESS_ONCE() macro calls, neither of which should be able to break things. This commit has passed significant rcutorture testing, with these additional additions to rcutorture slated for 3.16. This commit has also been exposed to -next testing. This change is available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next for you to fetch changes up to 765a3f4fed708ae429ee095914a7897acb3a65bd: rcu: Provide grace-period piggybacking API (2014-03-20 17:12:25 -0700) Paul E. McKenney (1): rcu: Provide grace-period piggybacking API include/linux/rcutiny.h | 10 include/linux/rcutree.h | 2 ++ kernel/rcu/tree.c | 62 + 3 files changed, 70 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the omap_dss2 tree with the drm tree
Hi Tomi,
Today's linux-next merge of the omap_dss2 tree got a conflict in
drivers/video/fbdev/exynos/Kconfig between commit 2e4e678aa8a4
("drm/exynos: Move dp driver from video/ to drm/") from the drm tree and
commits 07e521b66cf0 ("video: exynos: Remove OF dependency for Exynos
DP") and 844901baede6 ("video: move fbdev to drivers/video/fbdev") from
the omap_dss2 tree.
git said this:
CONFLICT (rename/rename): Rename
"drivers/video/exynos/exynos_dp_reg.h"->"drivers/gpu/drm/exynos/exynos_dp_reg.h"
in branch "HEAD" rename
"drivers/video/exynos/exynos_dp_reg.h"->"drivers/video/fbdev/exynos/exynos_dp_reg.h"
in "omap_dss2/for-next"
CONFLICT (rename/rename): Rename
"drivers/video/exynos/exynos_dp_reg.c"->"drivers/gpu/drm/exynos/exynos_dp_reg.c"
in branch "HEAD" rename
"drivers/video/exynos/exynos_dp_reg.c"->"drivers/video/fbdev/exynos/exynos_dp_reg.c"
in "omap_dss2/for-next"
CONFLICT (rename/rename): Rename
"drivers/video/exynos/exynos_dp_core.h"->"drivers/gpu/drm/exynos/exynos_dp_core.h"
in branch "HEAD" rename
"drivers/video/exynos/exynos_dp_core.h"->"drivers/video/fbdev/exynos/exynos_dp_core.h"
in "omap_dss2/for-next"
CONFLICT (rename/rename): Rename
"drivers/video/exynos/exynos_dp_core.c"->"drivers/gpu/drm/exynos/exynos_dp_core.c"
in branch "HEAD" rename
"drivers/video/exynos/exynos_dp_core.c"->"drivers/video/fbdev/exynos/exynos_dp_core.c"
in "omap_dss2/for-next"
I fixed it up and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgphct2_aXrM9.pgp
Description: PGP signature
Re: [dm-devel] [PATCH RFC v1 00/01] dm-lightnvm introduction
On 03/24/2014 08:08 PM, David Lang wrote: > On Fri, 21 Mar 2014, Matias Bjorling wrote: > >> On 03/21/2014 02:06 AM, Joe Thornber wrote: >>> Hi Matias, >>> >>> This looks really interesting and I'd love to get involved. Do you >>> have any recommendations for what hardware I should pick up? >> >> Hi Joe, >> >> The most easily available platform is OpenSSD >> (http://www.openssd-project.org). It's a little old, but still very >> functional. When there's a good firmware implementation, I think it will >> be easier for the custom SSD vendor's to jump on board with their own >> firmware. > > Is this something that would make sense to use for accessing the NAND > flash that's being used on routers nowdays? Talking with the OpenWRT > folks, they are having trouble supporting those devices because the > flash may contain defects and squashfs doesn't work in such an > environment. This appears to be the one remaining problem preventing a > lot of new routers from working. > > If this can work as a shim layer between the hardware and the filesystem > for OpenWRT, you would gain a very large userbase rather quickly. It's possible and would make sense. However, I'm not sure that its the best choice. >From what I can see, OpenWRT routers expose their flash through mtd. Couldn't UBIFS be a better choice for this, instead of squashfs? > > David Lang -- 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: [dm-devel] [PATCH RFC v1 01/01] dm-lightnvm: An open FTL for open firmware SSDs
On 03/24/2014 07:22 PM, Akira Hayakawa wrote: > Hi, Matias, > > Sorry for jumping in. I am interested in this new feature, too. > >>> Does it even make sense to expose the underlying devices as block >>> devices? It surely would help to send this together with a driver >>> that you plan to use it on top of. >>> >> >> Agree, an underlying driver is missing. My first plan is to get a draft >> firmware for the OpenSSD to be stable and expose its primitives >> (read/write/erase) up through the ATA/SCSI stack. Communicating using >> vendor specific codes. > Hi Akira, Indeed. Most of Mohit's work can be applied with this layer. In the same breath we could also look into nameless writes. It would up open for a new design for co-operating file systems. > Exposing FTL to the host layer has potential to share mapping in cache > software (or driver) and the device. > The "Unified Address Space" in the slides below addresses the problem of two > levels of indirection. > http://www1.unine.ch/eurosys2012/posters/saxena.pdf > > Developing API to share mapping between driver and the device sounds > interesting, too. > > -- > Akira > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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] bonding: Inactive slaves should keep inactive flag's value to 1 in tlb and alb mode.
On 2014/3/25 11:00, Zheng Li wrote:
> In bond mode tlb and alb, inactive slaves should keep inactive flag to
> 1 to refuse to receive broadcast packets. Now, active slave send broadcast
> packets
> (for example ARP requests) which will arrive inactive slaves on same host
> from switch,
> but inactive slave's inactive flag is zero that cause bridge receive the
> broadcast
> packets to produce a wrong entry in forward table. Typical situation is domu
> send some
> ARP request which go out from dom0 bond's active slave, then the ARP
> broadcast request
> packets go back to inactive slave from switch, because the inactive slave's
> inactive
> flag is zero, kernel will receive the packets and pass them to bridge, that
> cause dom0's
> bridge map domu's MAC address to port of bond, bridge should map domu's MAC
> to port of vif.
>
> Signed-off-by: Zheng Li
> ---
> drivers/net/bonding/bond_main.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index e5628fc..8761df6 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -3062,7 +3062,7 @@ static int bond_open(struct net_device *bond_dev)
> && (slave != bond->curr_active_slave)) {
> bond_set_slave_inactive_flags(slave,
>
> BOND_SLAVE_NOTIFY_NOW);
> - } else {
> + } else if (!bond_is_lb(bond)) {
> bond_set_slave_active_flags(slave,
>
> BOND_SLAVE_NOTIFY_NOW);
> }
>
I think you did not fix the problem completely, the state monitor will change
the status for the slaves
and the inactive slave still could receive the broadcast.
Regards
Ding
--
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: [dm-devel] [PATCH RFC v1 01/01] dm-lightnvm: An open FTL for open firmware SSDs
On 03/23/2014 11:13 PM, Bart Van Assche wrote: > On 03/21/14 16:37, Christoph Hellwig wrote: >> Just curious: why do you think implementing this as a block remapper >> inside device mapper is a better idea than as a blk-mq driver? >> >> At the request layer you already get a lot of infrastructure for all the >> queueing infrastructure for free, as well as all kinds of other helpers. >> And the driver never remaps bios anyway but always submits new ones as >> far as I can tell. >> >> Does it even make sense to expose the underlying devices as block >> devices? It surely would help to send this together with a driver >> that you plan to use it on top of. > > There might be some overlap between the functionality available in the > lightnvm driver and the WalB driver announced last year. That last > driver might have a wider user base and hence may have received more > testing. See also http://thread.gmane.org/gmane.linux.file-systems/75124. > Hi Bart, Thanks! There seems to be a little bit that can be reused. It does seem from the github page that there haven't been any development since its been posted. Maybe the development is moved elsewhere? > Bart. > -- 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 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Ping.. On 03/10/2014 10:01 PM, Xiao Guangrong wrote: > This patchset is splited from my previous patchset: > [PATCH v3 00/15] KVM: MMU: locklessly write-protect > that can be found at: > https://lkml.org/lkml/2013/10/23/265 > > Changelog v4 : > - add more comments for patch 5 and thank for Marcelo's review > > Xiao Guangrong (5): > Revert "KVM: Simplify kvm->tlbs_dirty handling" > KVM: MMU: properly check last spte in fast_page_fault() > KVM: MMU: lazily drop large spte > KVM: MMU: flush tlb if the spte can be locklessly modified > KVM: MMU: flush tlb out of mmu lock when write-protect the sptes > > arch/x86/kvm/mmu.c | 72 > ++ > arch/x86/kvm/mmu.h | 14 + > arch/x86/kvm/paging_tmpl.h | 7 ++--- > arch/x86/kvm/x86.c | 20 ++--- > include/linux/kvm_host.h | 4 +-- > virt/kvm/kvm_main.c| 5 +++- > 6 files changed, 85 insertions(+), 37 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH RFC v1 00/01] dm-lightnvm introduction
On Fri, 21 Mar 2014, Matias Bjorling wrote: On 03/21/2014 02:06 AM, Joe Thornber wrote: Hi Matias, This looks really interesting and I'd love to get involved. Do you have any recommendations for what hardware I should pick up? Hi Joe, The most easily available platform is OpenSSD (http://www.openssd-project.org). It's a little old, but still very functional. When there's a good firmware implementation, I think it will be easier for the custom SSD vendor's to jump on board with their own firmware. Is this something that would make sense to use for accessing the NAND flash that's being used on routers nowdays? Talking with the OpenWRT folks, they are having trouble supporting those devices because the flash may contain defects and squashfs doesn't work in such an environment. This appears to be the one remaining problem preventing a lot of new routers from working. If this can work as a shim layer between the hardware and the filesystem for OpenWRT, you would gain a very large userbase rather quickly. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the modules tree
Hi Rusty,
After merging the modules tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/thread_info.h:11:0,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:18,
from include/linux/spinlock.h:50,
from include/linux/wait.h:8,
from include/linux/fs.h:6,
from drivers/staging/speakup/spk_types.h:9,
from drivers/staging/speakup/spk_priv.h:27,
from drivers/staging/speakup/speakup_acntsa.c:26:
include/linux/bug.h:33:45: error: negative width in bit-field ''
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/kernel.h:848:3: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
BUILD_BUG_ON_ZERO((perms) > 0777) +\
^
include/linux/sysfs.h:75:12: note: in expansion of macro
'VERIFY_OCTAL_PERMISSIONS'
.mode = VERIFY_OCTAL_PERMISSIONS(_mode) }, \
^
drivers/staging/speakup/speakup_acntsa.c:50:2: note: in expansion of macro
'__ATTR'
__ATTR(caps_start, USER_RW, spk_var_show, spk_var_store);
^
And many more ...
Exposed by commit 58f86cc89c33 ("VERIFY_OCTAL_PERMISSIONS: stricter
checking for sysfs perms").
drivers/staging/speakup/speakup.h has
#define USER_RW (S_IFREG|S_IRUGO|S_IWUGO)
and others
which are used in many attribute definitions (and only in those
definitions). So I added this fixup patch (Rusty you might like to add
this to your tree):
From: Stephen Rothwell
Date: Tue, 25 Mar 2014 13:54:38 +1100
Subject: [PATCH] VERIFY_OCTAL_PERMISSIONS: fix up for staging/speakup
Signed-off-by: Stephen Rothwell
---
drivers/staging/speakup/speakup.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/speakup/speakup.h
b/drivers/staging/speakup/speakup.h
index 0126f714821a..578824a9829d 100644
--- a/drivers/staging/speakup/speakup.h
+++ b/drivers/staging/speakup/speakup.h
@@ -10,10 +10,10 @@
#define MAX_DESC_LEN 72
/* proc permissions */
-#define USER_R (S_IFREG|S_IRUGO)
-#define USER_W (S_IFREG|S_IWUGO)
-#define USER_RW (S_IFREG|S_IRUGO|S_IWUGO)
-#define ROOT_W (S_IFREG|S_IRUGO|S_IWUSR)
+#define USER_R S_IRUGO
+#define USER_W S_IWUGO
+#define USER_RW (S_IRUGO|S_IWUGO)
+#define ROOT_W (S_IRUGO|S_IWUSR)
#define TOGGLE_0 .u.n = {NULL, 0, 0, 1, 0, 0, NULL }
#define TOGGLE_1 .u.n = {NULL, 1, 0, 1, 0, 0, NULL }
--
1.9.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpxVIvFA_UGB.pgp
Description: PGP signature
Re: Re: [PATCH 3.4 93/99] iwlwifi: always copy first 16 bytes of commands
On Sat, 2014-03-22 at 22:01 +0100, Andreas Sturmlechner wrote:
> Original Message from: Ben Hutchings
> >
> > Andreas, could you test whether this regression is also present in
> > 3.2.55? This patch is based on my backport for 3.2.y.
> >
>
> 3.2.55 is OK here.
One piece of my backport to 3.2.y went missing in the forward-port to
3.4.y. Can you test 3.4.83 with this patch on top?
Ben.
---
From: Ben Hutchings
Date: Tue, 25 Mar 2014 02:49:14 +
Subject: iwlwifi: Complete backport of "iwlwifi: always copy first 16 bytes of
commands"
Linux 3.4.83 included an incomplete backport of commit
8a964f44e01ad3bbc208c3e80d931ba91b9ea786 ('iwlwifi: always copy first
16 bytes of commands') which causes a regression for this driver.
This is the missing piece.
Reported-by: Andreas Sturmlechner
Cc: Johannes Berg
Cc: Emmanuel Grumbach
Cc: Jianguo Wu
Signed-off-by: Ben Hutchings
---
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
@@ -825,14 +825,15 @@ static int iwl_enqueue_hcmd(struct iwl_trans *trans,
struct iwl_host_cmd *cmd)
trace_idx = 1;
#endif
+ /* map the remaining (adjusted) nocopy/dup fragments */
for (i = 0; i < IWL_MAX_CMD_TFDS; i++) {
- if (!cmd->len[i])
+ if (!cmdlen[i])
continue;
if (!(cmd->dataflags[i] & IWL_HCMD_DFL_NOCOPY))
continue;
phys_addr = dma_map_single(trans->dev,
- (void *)cmd->data[i],
- cmd->len[i], DMA_BIDIRECTIONAL);
+ (void *)cmddata[i],
+ cmdlen[i], DMA_BIDIRECTIONAL);
if (dma_mapping_error(trans->dev, phys_addr)) {
iwlagn_unmap_tfd(trans, out_meta,
>tfds[q->write_ptr],
--
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.
signature.asc
Description: This is a digitally signed message part
[PATCH] bonding: Inactive slaves should keep inactive flag's value to 1 in tlb and alb mode.
In bond mode tlb and alb, inactive slaves should keep inactive flag to
1 to refuse to receive broadcast packets. Now, active slave send broadcast
packets
(for example ARP requests) which will arrive inactive slaves on same host from
switch,
but inactive slave's inactive flag is zero that cause bridge receive the
broadcast
packets to produce a wrong entry in forward table. Typical situation is domu
send some
ARP request which go out from dom0 bond's active slave, then the ARP broadcast
request
packets go back to inactive slave from switch, because the inactive slave's
inactive
flag is zero, kernel will receive the packets and pass them to bridge, that
cause dom0's
bridge map domu's MAC address to port of bond, bridge should map domu's MAC to
port of vif.
Signed-off-by: Zheng Li
---
drivers/net/bonding/bond_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index e5628fc..8761df6 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3062,7 +3062,7 @@ static int bond_open(struct net_device *bond_dev)
&& (slave != bond->curr_active_slave)) {
bond_set_slave_inactive_flags(slave,
BOND_SLAVE_NOTIFY_NOW);
- } else {
+ } else if (!bond_is_lb(bond)) {
bond_set_slave_active_flags(slave,
BOND_SLAVE_NOTIFY_NOW);
}
--
1.7.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 3.14-rc8
I delayed things a day from my normal schedule, hoping I'd feel more comfortable doing a 3.14 release, but that was not to be. So here's an rc8, and I expect to do the final 3.14 release next weekend. There wasn't that much scary stuff going on, but there's a few vfs fixes still pending, and we did end up having some interesting core fixes last week too (not new regressions, but newly detected by Trinity. Kudos to Hugh Dickins for figuring them out and fixing the causes). There's also some networking fixes and random noise (mainly MIPS). So I really wanted another week before release after all. Linus --- Alex Smith (1): MIPS: Fix possible build error with transparent hugepages enabled Andreas Herrmann (1): MIPS: Octeon: Fix warning in of_device_alloc on cn3xxx Arnaldo Carvalho de Melo (1): perf bench numa: Make no args mean 'run all tests' Ben Pfaff (1): openvswitch: Correctly report flow used times for first 5 minutes after boot. Ben Widawsky (1): drm/i915: Fix PSR programming Benedikt Spranger (1): net: cpsw: do not register cpts twice Bjorn Helgaas (1): Revert "[PATCH] Insert GART region into resource map" Bjørn Mork (1): net: cdc_ncm: fix control message ordering Boris BREZILLON (1): ARM: at91: fix network interface ordering for sama5d36 Charles Keepax (1): ALSA: compress: Pass through return value of open ops callback Chris Wilson (1): drm/i915: Disable stolen memory when DMAR is active Christian Riesch (2): net: davinci_emac: Replace devm_request_irq with request_irq net: davinci_emac: Fix rollback of emac_dev_open() Clemens Ladisch (1): ALSA: oxygen: Xonar DG(X): fix Stereo Upmixing regression Colin Ian King (1): MIPS: Octeon: Fix fall through on bar type OCTEON_DMA_BAR_TYPE_SMALL Daniel Kurtz (1): drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c Daniel Vetter (2): drm/i915: Don't enable display error interrupts from the start drm: Fix use-after-free in the shadow-attache exit code Dave Jones (2): brcmfmac: fix skb leak in brcmf_sdio_txpkt_prep_sg error path. block: free q->flush_rq in blk_init_allocated_queue error paths Dave Kleikamp (1): sparc64: don't treat 64-bit syscall return codes as 32-bit David Miller (1): sparc: serial: Clean up the locking for -rt David S. Miller (1): sparc64: Make sure %pil interrupts are enabled during hypervisor yield. David Stevens (2): vxlan: fix potential NULL dereference in arp_reduce() vxlan: fix nonfunctional neigh_reduce() Deng-Cheng Zhu (4): MIPS: APRP: Fix the linking of rtlx interrupt hook MIPS: APRP: Unregister rtlx interrupt hook at module exit MIPS: APRP: Choose the correct VPE loader by fixing the linking MIPS: math-emu: Fix prefx detection and COP1X function field definition Doug Wilson (1): sparc64:tsb.c:use array size macro rather than number Eric Dumazet (1): tcp: syncookies: do not use getnstimeofday() Erik Hugne (1): tipc: fix spinlock recursion bug for failed subscriptions Felix Fietkau (1): ath9k_hw: fix unreachable code in baseband hang detection code Fernando Luis Vázquez Cao (1): HID: hidraw: fix warning destroying hidraw device files after parent Frank Praznik (1): HID: sony: Fix work queue issues. Helge Deller (2): partly revert commit 8a10bc9: parisc/sti_console: prefer Linux fonts over built-in ROM fonts parisc: wire up sys_utimes Helmut Schaa (1): ath9k: Fix sequence number assignment for non-data frames Huacai Chen (1): MIPS: FPU: Fix conflict of register usage Hugh Dickins (2): mm: fix bad rss-counter if remap_file_pages raced migration mm: fix swapops.h:131 bug if remap_file_pages raced migration Jani Nikula (1): Revert "drm/i915: don't touch the VDD when disabling the panel" Jarno Rajahalme (2): openvswitch: Read tcp flags only then the tranport header is present. openvswitch: Fix race. Jens Axboe (1): mtip32xx: fix bad use of smp_processor_id() Jim Quinlan (1): MIPS: Make local_irq_disable macro safe for non-Mipsr2 Jiri Pirko (1): ovs: fix dp check in ovs_dp_reset_user_features Joe Perches (1): MAINTAINERS: Add linux.n...@intel.com to INTEL ETHERNET DRIVERS John David Anglin (1): parisc: Remove unused CONFIG_PARISC_TMPALIAS code Lars Persson (1): MIPS: Fix syscall tracing interface Li RongQing (1): netpoll: fix the skb check in pkt_is_ns Li Zefan (1): cgroup: fix a failure path in create_css() Linus Torvalds (2): futex: revert back to the explicit waiter counting code Linux 3.14-rc8 Manuel Lauss (1): MIPS: Alchemy: Fix unchecked kstrtoul return value Markos Chandras (2): MIPS: bcm47xx: Include missing errno.h for ENXIO MIPS: asm: syscall: Fix copying system call arguments Michael Chan (3): cnic: Use proper ulp_ops
Re: [PATCH] staging/usbip: fix store_attach() sscanf return value check
On 03/24/2014 06:38 PM, Greg KH wrote: On Mon, Mar 24, 2014 at 05:12:09PM -0600, Shuah Khan wrote: Fix commit - 88fa1ebfa21b5deaaad2dc88ecd9f6af91796cf7 What do you mean by this line? Nothing really. Sloppiness on my part. I was keeping notes as I was chasing the problem and those ended up in the change log. Sorry about. Will fix the change log and resend the patch. -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RESEND: PATCH[60485 Bug adding breakpoint for msi-pci]
> From: nickkra...@sympatico.ca > To: a...@lxorguk.ukuu.org.uk > CC: linux-m...@linux-mips.org; linux-kernel@vger.kernel.org; > r...@linux-mips.org > Subject: RE: PATCH[60485 Bug adding breakpoint] > Date: Mon, 24 Mar 2014 00:19:29 + > > > > > > Here is my new patch as corrected for the the bug 60845. > https://bugzilla.kernel.org/show_bug.cgi?id=60845 > This is the link to the bug and my comments / conversation on to get the > corrections needed. > Below is my patch for the bug, please let me know if it gets added finally > Alan . > > --- linux-3.13.6/arch/mips/pci/msi-octeon.c.orig2014-03-22 > 17:32:44.762754254 -0400 > +++ linux-3.13.6/arch/mips/pci/msi-octeon.c2014-03-22 17:34:19.974753699 > -0400 > @@ -150,6 +150,7 @@ msi_irq_allocated: > msg.address_lo = > ((128ul << 20) + CVMX_PCI_MSI_RCV) & 0x; > msg.address_hi = ((128ul << 20) + CVMX_PCI_MSI_RCV)>> 32; > +break; > case OCTEON_DMA_BAR_TYPE_BIG: > /* When using big bar, Bar 0 is based at 0 */ > msg.address_lo = (0 + CVMX_PCI_MSI_RCV) & 0x; > Signed-off-by: nickkra...@sympatico.ca > Nick > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH RFC v1 01/01] dm-lightnvm: An open FTL for open firmware SSDs
Hi, Matias, Sorry for jumping in. I am interested in this new feature, too. > > Does it even make sense to expose the underlying devices as block > > devices? It surely would help to send this together with a driver > > that you plan to use it on top of. > > > > Agree, an underlying driver is missing. My first plan is to get a draft > firmware for the OpenSSD to be stable and expose its primitives > (read/write/erase) up through the ATA/SCSI stack. Communicating using > vendor specific codes. Exposing FTL to the host layer has potential to share mapping in cache software (or driver) and the device. The "Unified Address Space" in the slides below addresses the problem of two levels of indirection. http://www1.unine.ch/eurosys2012/posters/saxena.pdf Developing API to share mapping between driver and the device sounds interesting, too. -- Akira -- 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 7/7] gpio: dwapb: use d->mask instead od BIT(bit)
On Sun, Mar 23, 2014 at 1:16 AM, Sebastian Andrzej Siewior wrote: > d->mask contains exact the same information as BIT(bit) so we could save > a few cycles here. > > Signed-off-by: Sebastian Andrzej Siewior > --- > drivers/gpio/gpio-dwapb.c | 25 - > 1 file changed, 12 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c > index 3c9cdda..ebfcf5c 100644 > --- a/drivers/gpio/gpio-dwapb.c > +++ b/drivers/gpio/gpio-dwapb.c > @@ -113,7 +113,7 @@ static void dwapb_irq_enable(struct irq_data *d) > > irq_gc_lock(igc); > val = readl(gpio->regs + GPIO_INTEN); > - val |= BIT(d->hwirq); > + val |= d->mask; > writel(val, gpio->regs + GPIO_INTEN); > irq_gc_unlock(igc); > } > @@ -126,7 +126,7 @@ static void dwapb_irq_disable(struct irq_data *d) > > irq_gc_lock(igc); > val = readl(gpio->regs + GPIO_INTEN); > - val &= ~BIT(d->hwirq); > + val &= d->mask; Shouldn't that be ~d->mask here? -- 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] compat_audit: allow it to work without asm/unistd32.h
On 03/25/2014 01:39 AM, Chris Metcalf wrote:
The problem is that audit_is_compat() is a dynamic test that the compiler
can't optimize away, so you end with an undefined reference to
audit_classify_compat_syscall().
For some reason audit_classify_compat_syscall() is declared as __weak
in ; usually the __weak tag is only provided on the definition.
But I suppose you could imagine providing a weak definition in lib/audit.c
itself.
I still believe that a function can be declared with __weak and replaced
by a strong definition later on (at link time).
But this is not the case anyway.
Or there could be a CONFIG_AUDIT_COMPAT symbol that architectures need to
set if they want to have audit_is_compat() return anything other than "false",
and then just use that symbol in the #ifdef in . In that
case the compiler would optimize away the call to
audit_classify_compat_syscall().
My guess is that the second option is probably cleanest.
Yep, but I don't want to add new CONFIG_AUDIT_COMPAT symbol just for
audit_is_compat() because it is only used in lib/audit.c(AUDIT_GENERIC).
Instead, I prefer
#ifdef CONFIG_AUDIT_COMPAT_GENERIC
#define audit_is_compat(arch) (...)
#else
#define audit_is_compat(arch) false
#endif
Thanks,
-Takahiro AKASHI
On 3/24/2014 12:21 PM, Eric Paris wrote:
I don't know tilegx, but I have replaced 223b24d807610 with
4b58841149dcaa5. I believe adding AUDIT_ARCH_COMPAT_GENERIC was
akashi-san's fix for this problem on mips. Is this a better fix?
Thanks
-Eric
On Thu, 2014-03-20 at 11:31 -0400, Chris Metcalf wrote:
For architectures that use the asm-generic syscall table for both
32- and 64-bit, there should be no need to provide a separate
; just using is sufficient.
Conditionalize use of on the one platform that
currently requires it (arm64). If another platform ends up needing
it we can create a suitable config flag at that point.
This change fixes the tilegx build failure seen in linux-next.
Signed-off-by: Chris Metcalf
---
By the way - I also note that commit 223b24d807610 that introduced
this also put an "#ifdef COMPAT_xxx" in a UAPI header. This seems
like a pretty clear signal that the added code should be in
linux/include/audit.h, not linux/uapi/include/audit.h. But here
I'm just focussing on getting tilegx to continue to build...
lib/compat_audit.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lib/compat_audit.c b/lib/compat_audit.c
index 873f75b640ab..e89a84b3fbe8 100644
--- a/lib/compat_audit.c
+++ b/lib/compat_audit.c
@@ -1,6 +1,11 @@
#include
#include
-#include
+#ifdef COMPAT_ARM64
+/* 64-bit syscalls are generic, but 32-bit are not. */
+# include
+#else
+# include
+#endif
unsigned compat_dir_class[] = {
#include
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/core/netpoll.c between commit c27f0872a344 ("netpoll: fix the skb
check in pkt_is_ns") from the net tree and commit 9c62a68d1311 ("netpoll:
Remove dead packet receive code (CONFIG_NETPOLL_TRAP)") from the net-next
tree.
I fixed it up (the latter removes the code fixed by the former, so I did
that) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpQKY2Y5Fd1Q.pgp
Description: PGP signature
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
Documentation/devicetree/bindings/net/micrel-ks8851.txt between commit
ebf4ad955d3e ("net: micrel : ks8851-ml: add vdd-supply support") from
the tree and commit e8f08ee0ad86 ("DT: net: document Ethernet bindings
in one place") from the net-next tree.
I fixed it up (maybe - see below) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc Documentation/devicetree/bindings/net/micrel-ks8851.txt
index 4fc392763611,8e20c04a1da1..
--- a/Documentation/devicetree/bindings/net/micrel-ks8851.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ks8851.txt
@@@ -4,7 -4,3 +4,6 @@@ Required properties
- compatible = "micrel,ks8851-ml" of parallel interface
- reg : 2 physical address and size of registers for data and command
- interrupts : interrupt connection
+
+Optional properties:
- - local-mac-address : Ethernet mac address to use
+- vdd-supply: supply for Ethernet mac
pgp2eq1lr4Gw7.pgp
Description: PGP signature
Re: linux-next: manual merge of the keystone tree with the arm-soc tree
On Mon, Mar 24, 2014 at 08:00:03PM -0400, Santosh Shilimkar wrote:
> On Monday 24 March 2014 07:55 PM, Stephen Rothwell wrote:
> > Hi Santosh,
> >
> > Today's linux-next merge of the keystone tree got a conflict in
> > arch/arm/boot/dts/Makefile between commit ba5a37e52194 ("ARM: mvebu: Move
> > kirkwood DT boards into mach-mvebu") from the arm-soc tree and commit
> > 400550ae7e77 ("ARM: dts: Build all keystone dt blobs") from the keystone
> > tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> >
> Looks fine. Thanks
wow, not even a mention of my original patch [1]. I also couldn't find
your patch [2] anywhere in the mailing list archives, not even google
could find it. The only place that commit was ever mentioned was this
very thread.
The patch I wrote was valid for v3.14-rc7 (the base where it was
written), I'd expect to, at a minimum, have a mention or a Reported-by
or at least see your patch in the mailing list.
Anyway, it's just a patch. Nevermind.
[1] http://marc.info/?l=linux-arm-kernel=139463982310448=2
[2]
https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux-keystone.git/commit/?h=next=400550ae7e778302a45d2952ac75907903e2610c
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3] shdma: add R-Car Audio DMAC peri peri driver
Hi Vinod, and all
Could you please teach me current status of this patch ??
> From: Kuninori Morimoto
>
> Add support Audio DMAC peri peri driver
> for Renesas R-Car Gen2 SoC, using 'shdma-base'
> DMA driver framework.
>
> Signed-off-by: Kuninori Morimoto
> ---
> v2 -> v3
>
> - modiry copyright
> - use %pad for dma_addr_t
> - use sizeof(*hoge) for devm_kzalloc()
>
> drivers/dma/sh/Kconfig |6 +
> drivers/dma/sh/Makefile|1 +
> drivers/dma/sh/rcar-audmapp.c | 320
>
> include/linux/platform_data/dma-rcar-audmapp.h | 34 +++
> 4 files changed, 361 insertions(+)
> create mode 100644 drivers/dma/sh/rcar-audmapp.c
> create mode 100644 include/linux/platform_data/dma-rcar-audmapp.h
>
> diff --git a/drivers/dma/sh/Kconfig b/drivers/dma/sh/Kconfig
> index dadd9e01..b4c8138 100644
> --- a/drivers/dma/sh/Kconfig
> +++ b/drivers/dma/sh/Kconfig
> @@ -29,6 +29,12 @@ config RCAR_HPB_DMAE
> help
> Enable support for the Renesas R-Car series DMA controllers.
>
> +config RCAR_AUDMAC_PP
> + tristate "Renesas R-Car Audio DMAC Peripheral Peripheral support"
> + depends on SH_DMAE_BASE
> + help
> + Enable support for the Renesas R-Car Audio DMAC Peripheral Peripheral
> controllers.
> +
> config SHDMA_R8A73A4
> def_bool y
> depends on ARCH_R8A73A4 && SH_DMAE != n
> diff --git a/drivers/dma/sh/Makefile b/drivers/dma/sh/Makefile
> index e856af2..1ce88b2 100644
> --- a/drivers/dma/sh/Makefile
> +++ b/drivers/dma/sh/Makefile
> @@ -7,3 +7,4 @@ endif
> shdma-objs := $(shdma-y)
> obj-$(CONFIG_SUDMAC) += sudmac.o
> obj-$(CONFIG_RCAR_HPB_DMAE) += rcar-hpbdma.o
> +obj-$(CONFIG_RCAR_AUDMAC_PP) += rcar-audmapp.o
> diff --git a/drivers/dma/sh/rcar-audmapp.c b/drivers/dma/sh/rcar-audmapp.c
> new file mode 100644
> index 000..72d7475
> --- /dev/null
> +++ b/drivers/dma/sh/rcar-audmapp.c
> @@ -0,0 +1,320 @@
> +/*
> + * This is for Renesas R-Car Audio-DMAC-peri-peri.
> + *
> + * Copyright (C) 2014 Renesas Electronics Corporation
> + * Copyright (C) 2014 Kuninori Morimoto
> + *
> + * based on the drivers/dma/sh/shdma.c
> + *
> + * Copyright (C) 2011-2012 Guennadi Liakhovetski
> + * Copyright (C) 2009 Nobuhiro Iwamatsu
> + * Copyright (C) 2009 Renesas Solutions, Inc. All rights reserved.
> + * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
> + *
> + * This is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * DMA register
> + */
> +#define PDMASAR 0x00
> +#define PDMADAR 0x04
> +#define PDMACHCR 0x0c
> +
> +/* PDMACHCR */
> +#define PDMACHCR_DE (1 << 0)
> +
> +#define AUDMAPP_MAX_CHANNELS 29
> +
> +/* Default MEMCPY transfer size = 2^2 = 4 bytes */
> +#define LOG2_DEFAULT_XFER_SIZE 2
> +#define AUDMAPP_SLAVE_NUMBER 256
> +#define AUDMAPP_LEN_MAX (16 * 1024 * 1024)
> +
> +struct audmapp_chan {
> + struct shdma_chan shdma_chan;
> + struct audmapp_slave_config *config;
> + void __iomem *base;
> +};
> +
> +struct audmapp_device {
> + struct shdma_dev shdma_dev;
> + struct audmapp_pdata *pdata;
> + struct device *dev;
> + void __iomem *chan_reg;
> +};
> +
> +#define to_chan(chan) container_of(chan, struct audmapp_chan, shdma_chan)
> +#define to_dev(chan) container_of(chan->shdma_chan.dma_chan.device, \
> + struct audmapp_device, shdma_dev.dma_dev)
> +
> +static void audmapp_write(struct audmapp_chan *auchan, u32 data, u32 reg)
> +{
> + struct audmapp_device *audev = to_dev(auchan);
> + struct device *dev = audev->dev;
> +
> + dev_dbg(dev, "w %p : %08x\n", auchan->base + reg, data);
> +
> + iowrite32(data, auchan->base + reg);
> +}
> +
> +static u32 audmapp_read(struct audmapp_chan *auchan, u32 reg)
> +{
> + return ioread32(auchan->base + reg);
> +}
> +
> +static void audmapp_halt(struct shdma_chan *schan)
> +{
> + struct audmapp_chan *auchan = to_chan(schan);
> + int i;
> +
> + audmapp_write(auchan, 0, PDMACHCR);
> +
> + for(i = 0; i < 1024; i++) {
> + if (0 == audmapp_read(auchan, PDMACHCR))
> + return;
> + udelay(1);
> + }
> +}
> +
> +static void audmapp_start_xfer(struct shdma_chan *schan,
> +struct shdma_desc *sdecs)
> +{
> + struct audmapp_chan *auchan = to_chan(schan);
> + struct audmapp_device *audev = to_dev(auchan);
> + struct audmapp_slave_config *cfg = auchan->config;
> + struct device *dev = audev->dev;
> + u32 chcr = cfg->chcr | PDMACHCR_DE;
> +
> + dev_dbg(dev, "src/dst/chcr
Re: [PATCH 1/2] staging: binder: add __user annotation in binder.c
Joe Perches wrote:
> On Tue, 2014-03-25 at 01:24 +0100, Mathieu Maret wrote:
> > Fix the following spare warning
>
> sparse
>
> > drivers/staging/android/binder.c:2691:21: warning: incorrect type in
> > argument 1 (different address spaces)
> []
> > diff --git a/drivers/staging/android/binder.c
> > b/drivers/staging/android/binder.c
> []
> > @@ -2688,7 +2688,7 @@ static long binder_ioctl(struct file *filp, unsigned
> > int cmd, unsigned long arg)
> []
> > - if (put_user(BINDER_CURRENT_PROTOCOL_VERSION, &((struct
> > binder_version *)ubuf)->protocol_version)) {
> > + if (put_user(BINDER_CURRENT_PROTOCOL_VERSION, &((struct
> > binder_version __user *)ubuf)->protocol_version)) {
>
> That's certainly one way to do it, but I'd suggest
> using a temporary instead
>
> drivers/staging/android/binder.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/android/binder.c
> b/drivers/staging/android/binder.c
> index cfe4bc8..1f5e249 100644
> --- a/drivers/staging/android/binder.c
> +++ b/drivers/staging/android/binder.c
> @@ -2683,16 +2683,20 @@ static long binder_ioctl(struct file *filp, unsigned
> int cmd, unsigned long arg)
> binder_free_thread(proc, thread);
> thread = NULL;
> break;
> - case BINDER_VERSION:
> + case BINDER_VERSION: {
> + struct binder_version __user *ver = ubuf;
> +
> if (size != sizeof(struct binder_version)) {
> ret = -EINVAL;
> goto err;
> }
> - if (put_user(BINDER_CURRENT_PROTOCOL_VERSION, &((struct
> binder_version *)ubuf)->protocol_version)) {
> + if (put_user(BINDER_CURRENT_PROTOCOL_VERSION,
> + >protocol_version)) {
> ret = -EINVAL;
> goto err;
> }
> break;
> + }
> default:
> ret = -EINVAL;
> goto err;
>
>
And you solve the issue with the line size btw.
Good move!
--
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] staging: binder: add __user annotation in binder.c
On Tue, 2014-03-25 at 01:24 +0100, Mathieu Maret wrote:
> Fix the following spare warning
sparse
> drivers/staging/android/binder.c:2691:21: warning: incorrect type in argument
> 1 (different address spaces)
[]
> diff --git a/drivers/staging/android/binder.c
> b/drivers/staging/android/binder.c
[]
> @@ -2688,7 +2688,7 @@ static long binder_ioctl(struct file *filp, unsigned
> int cmd, unsigned long arg)
[]
> - if (put_user(BINDER_CURRENT_PROTOCOL_VERSION, &((struct
> binder_version *)ubuf)->protocol_version)) {
> + if (put_user(BINDER_CURRENT_PROTOCOL_VERSION, &((struct
> binder_version __user *)ubuf)->protocol_version)) {
That's certainly one way to do it, but I'd suggest
using a temporary instead
drivers/staging/android/binder.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
index cfe4bc8..1f5e249 100644
--- a/drivers/staging/android/binder.c
+++ b/drivers/staging/android/binder.c
@@ -2683,16 +2683,20 @@ static long binder_ioctl(struct file *filp, unsigned
int cmd, unsigned long arg)
binder_free_thread(proc, thread);
thread = NULL;
break;
- case BINDER_VERSION:
+ case BINDER_VERSION: {
+ struct binder_version __user *ver = ubuf;
+
if (size != sizeof(struct binder_version)) {
ret = -EINVAL;
goto err;
}
- if (put_user(BINDER_CURRENT_PROTOCOL_VERSION, &((struct
binder_version *)ubuf)->protocol_version)) {
+ if (put_user(BINDER_CURRENT_PROTOCOL_VERSION,
+>protocol_version)) {
ret = -EINVAL;
goto err;
}
break;
+ }
default:
ret = -EINVAL;
goto 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/
Re: [git pull] vfs fixes
Just to clarify: the current vfs tree from Al works for you, no new issues? I was delaying the release first a day, and now I think I'll just do an rc8 after all (and do the final 3.14 next weekend), but I'd like to be sure what the status of Al's tree is. Al, can you send a new pull request with fixed information (assuming I understood correctly and everything in vfs-land works for Sedat). > P.S.: [Off-topic] With vanilla -66 kernel I have some OOPS in the > oom[1..5] tests of LTP. Whom to adress? mm-folks? Yes, please send to -mm (and cc lkml and me). Linus -- 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: fs: gpf in simple_setattr
On 03/24/2014 05:48 PM, Jan Kara wrote: >[ 339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0 >[eventpoll] 84666040 88056c73e7b0 (null) OK, great. So finally we have something useful. We know we have problems with [eventpoll] dentry. That is actually a special filesystem not mounted anywhere - likely you get to that dentry through/proc//fd/. Now eventpoll is interesting because it uses single anon inode for all eventpoll instances. And that inode should stay in place as long as eventpoll filesystem exists. So it's not clear how come that inode is freed. The basic check of handling of inode use count didn't find anything suspicious. But I can check in more detail and if I fail, we now have a pretty narrow area where to look... Seems like it's not specific to eventpoll, I saw the same error message with "eventfd" and "perf_event". Thanks, Sasha -- 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/usbip: fix store_attach() sscanf return value check
On Mon, Mar 24, 2014 at 05:12:09PM -0600, Shuah Khan wrote:
> Fix commit - 88fa1ebfa21b5deaaad2dc88ecd9f6af91796cf7
What do you mean by this line?
> This commit added return value check for sscanf() that parses the
> input buffer for four input items. However, the return value check
> is incorrect, as it checks for one input item instead of four which
> is what it is expecting in the input buffer. As a result, sscanf()
> will always fail even when the input buffer is correct.
>
> Signed-off-by: Shuah Khan
> ---
> drivers/staging/usbip/vhci_sysfs.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/usbip/vhci_sysfs.c
> b/drivers/staging/usbip/vhci_sysfs.c
> index e098032..1ff24e9 100644
> --- a/drivers/staging/usbip/vhci_sysfs.c
> +++ b/drivers/staging/usbip/vhci_sysfs.c
> @@ -183,7 +183,7 @@ static ssize_t store_attach(struct device *dev, struct
> device_attribute *attr,
>* @devid: unique device identifier in a remote host
>* @speed: usb device speed in a remote host
>*/
> - if (sscanf(buf, "%u %u %u %u", , , , ) != 1)
> + if (sscanf(buf, "%u %u %u %u", , , , ) != 4)
> return -EINVAL;
>
> usbip_dbg_vhci_sysfs("rhport(%u) sockfd(%u) devid(%u) speed(%u)\n",
> --
> 1.7.10.4
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND: RFC PATCH 0/3] Add Keystone pcie driver
This is a RFC to add Keystone pcie driver. I had some earlier discussion on the pcie mailing about this driver and at that time I didn't have the driver ported to dw core driver. I now have a driver working with intel's e1000e ethernet driver and want to review this RFC on this list. Kestone PCIE hardware is based on dw version 3.65. It lacks ATU port and standard MSI controller found in newer version of the dw hardware. This version uses registers in PCIE application space to configure MSI controller. It has 4 host irqs for legacy IRQs A/B/C/D and 8 host irqs to muliplex 32 MSI irqs. Also has one host irq line for errors. Please review and provide your comments. CC: Jingoo Han CC: Bjorn Helgaas CC: Kukjin Kim CC: Richard Zhu CC: Shawn Guo CC: Mohit Kumar CC: Santosh Shilimkar Murali Karicheri (3): ARM: keystone: add pcie related options pci: designware: enhancements to support keystone pcie pcie: keystone: add pcie driver based on designware core driver .../devicetree/bindings/pci/pcie-keystone.txt | 32 + arch/arm/mach-keystone/Kconfig |2 + drivers/pci/host/Kconfig |5 + drivers/pci/host/Makefile |1 + drivers/pci/host/k2-platform.c | 191 + drivers/pci/host/pci-exynos.c |2 +- drivers/pci/host/pci-imx6.c|2 +- drivers/pci/host/pcie-designware.c | 99 ++- drivers/pci/host/pcie-designware.h | 14 +- drivers/pci/host/pcie-keystone.c | 860 drivers/pci/host/pcie-ks-pdata.h | 19 + drivers/pci/quirks.c | 12 + 12 files changed, 1203 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/pcie-keystone.txt create mode 100644 drivers/pci/host/k2-platform.c create mode 100644 drivers/pci/host/pcie-keystone.c create mode 100644 drivers/pci/host/pcie-ks-pdata.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND: RFC PATCH 2/3] pci: designware: enhancements to support keystone pcie
keystone pcie hardware is based on designware hw version 3.65.
There is no support for ATU port and have registers in
application space to configure inbound/outbound access. Also
doesn't support PCI PVM option. So the MSI IRQ registers available
in application space is used to mask/unmask/enable the MSI IRQs.
This requires changes to designware core driver to support the
keystone pcie driver.
Also modified affected drivers to work with the APIs that
are modified for to keystone pcie driver.
CC: Jingoo Han
CC: Bjorn Helgaas
CC: Kukjin Kim
CC: Richard Zhu
CC: Shawn Guo
CC: Mohit Kumar
CC: Santosh Shilimkar
Signed-off-by: Murali Karicheri
---
drivers/pci/host/pci-exynos.c |2 +-
drivers/pci/host/pci-imx6.c|2 +-
drivers/pci/host/pcie-designware.c | 99
drivers/pci/host/pcie-designware.h | 14 -
4 files changed, 81 insertions(+), 36 deletions(-)
diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index 24beed3..3cae9b1 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -546,7 +546,7 @@ static int add_pcie_port(struct pcie_port *pp, struct
platform_device *pdev)
pp->ops = _pcie_host_ops;
spin_lock_init(>conf_lock);
- ret = dw_pcie_host_init(pp);
+ ret = dw_pcie_host_init(pp, NULL, NULL);
if (ret) {
dev_err(>dev, "failed to initialize host\n");
return ret;
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index bd70af8..0d77047 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -397,7 +397,7 @@ static int imx6_add_pcie_port(struct pcie_port *pp,
pp->ops = _pcie_host_ops;
spin_lock_init(>conf_lock);
- ret = dw_pcie_host_init(pp);
+ ret = dw_pcie_host_init(pp, NULL, NULL);
if (ret) {
dev_err(>dev, "failed to initialize host\n");
return ret;
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index e33b68b..02d4d25 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -248,11 +248,15 @@ static int assign_irq(int no_irqs, struct msi_desc *desc,
int *pos)
irq_alloc_descs((irq + i), (irq + i), 1, 0);
irq_set_msi_desc(irq + i, desc);
/*Enable corresponding interrupt in MSI interrupt controller */
- res = ((pos0 + i) / 32) * 12;
- bit = (pos0 + i) % 32;
- dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, );
- val |= 1 << bit;
- dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, val);
+ if (!(pp->version & DW_VERSION_PRE_3_70)) {
+ res = ((pos0 + i) / 32) * 12;
+ bit = (pos0 + i) % 32;
+ dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
+4, );
+ val |= 1 << bit;
+ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
+4, val);
+ }
i++;
}
@@ -288,11 +292,13 @@ static void clear_irq(unsigned int irq)
clear_bit(pos, pp->msi_irq_in_use);
/* Disable corresponding interrupt on MSI interrupt controller */
- res = (pos / 32) * 12;
- bit = pos % 32;
- dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, );
- val &= ~(1 << bit);
- dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, val);
+ if (!(pp->version & DW_VERSION_PRE_3_70)) {
+ res = (pos / 32) * 12;
+ bit = pos % 32;
+ dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, );
+ val &= ~(1 << bit);
+ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, val);
+ }
}
static int dw_msi_setup_irq(struct msi_chip *chip, struct pci_dev *pdev,
@@ -326,7 +332,10 @@ static int dw_msi_setup_irq(struct msi_chip *chip, struct
pci_dev *pdev,
msg_ctr);
desc->msi_attrib.multiple = msgvec;
- msg.address_lo = virt_to_phys((void *)pp->msi_data);
+ if (pp->ops->get_msi_data)
+ msg.address_lo = pp->ops->get_msi_data(pp);
+ else
+ msg.address_lo = virt_to_phys((void *)pp->msi_data);
msg.address_hi = 0x0;
msg.data = pos;
write_msi_msg(irq, );
@@ -366,14 +375,27 @@ static const struct irq_domain_ops msi_domain_ops = {
.map = dw_pcie_msi_map,
};
-int __init dw_pcie_host_init(struct pcie_port *pp)
+int __init dw_pcie_host_init(struct pcie_port *pp, struct hw_pci *hw,
+ const struct irq_domain_ops *irq_ops)
{
struct device_node *np = pp->dev->of_node;
- struct of_pci_range range;
+ const struct irq_domain_ops
[RESEND: RFC PATCH 3/3] pcie: keystone: add pcie driver based on designware core driver
keystone pcie hardware is based on designware version 3.65. This
doesn't support standard MSI controller and ATU port available
on newer version of the designware hardware. In keystone dw hardware
the application register space implements the legacy and MSI
irq controller registers and has registers to allow outbound and
inbound translations. So the outbound/inbound configuration is
done by the keystone pcie driver.
Driver needs to handle irq as there are EOI registers available to
ack the interrupt after the same is acked by the end point device
driver. This requires irqchip implementation for legacy and MSI
irq handling. The driver however re-uses functions from dw core
wherever possible by making their prototype available in the dw
header file and calling the same from the keystone pcie driver.
Also add dts binding documentation for configuration details.
CC: Jingoo Han
CC: Bjorn Helgaas
CC: Kukjin Kim
CC: Richard Zhu
CC: Shawn Guo
CC: Mohit Kumar
CC: Santosh Shilimkar
Signed-off-by: Murali Karicheri
---
.../devicetree/bindings/pci/pcie-keystone.txt | 32 +
drivers/pci/host/Kconfig |5 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/k2-platform.c | 191 +
drivers/pci/host/pcie-keystone.c | 860
drivers/pci/host/pcie-ks-pdata.h | 19 +
drivers/pci/quirks.c | 12 +
7 files changed, 1120 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/pcie-keystone.txt
create mode 100644 drivers/pci/host/k2-platform.c
create mode 100644 drivers/pci/host/pcie-keystone.c
create mode 100644 drivers/pci/host/pcie-ks-pdata.h
diff --git a/Documentation/devicetree/bindings/pci/pcie-keystone.txt
b/Documentation/devicetree/bindings/pci/pcie-keystone.txt
new file mode 100644
index 000..b7b7651
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pcie-keystone.txt
@@ -0,0 +1,32 @@
+Keystone PCIE Root complex device tree bindings
+---
+
+Sample bindings shown below:-
+
+ - Remove enable-linktrain if boot loader already does Link training and do EP
+ configuration.
+ - To Disable SERDES initialization during Linux boot up, remove the
"reg_serdes"
+ reg values from the reg property.
+
+ pcie@2180 {
+ compatible = "ti,keystone2-pcie";
+ device_type = "pci";
+ clocks = <>;
+ clock-names = "pcie";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ reg = <0x2180 0x1000>, <0x0262014c 4>, <0x0232 0x4000>;
+ reg-names = "reg_rc_app", "reg_devcfg", "reg_serdes";
+ interrupts =<0 26 0xf01>, <0 27 0xf01>, <0 28 0xf01>, <0 29
0xf01>,
+ <0 30 0xf01>, <0 31 0xf01>, <0 32 0xf01>, <0 33
0xf01>,
+ <0 34 0xf01>, <0 35 0xf01>, <0 36 0xf01>, <0 37
0xf01>,
+ <0 38 0xf01>; /* Error IRQ */
+
+ ranges = <0x0800 0 0x21801000 0x21801000 0 0x0002000 /*
Configuration space */
+ 0x8100 0 0 0x2400 0 0x4000 /*
downstream I/O */
+ 0x8200 0 0x5000 0x5000 0 0x1000>; /*
non-prefetchable memory */
+
+ num-lanes = <2>;
+ ti,enable-linktrain;
+ };
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 47d46c6..9e45260 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -33,4 +33,9 @@ config PCI_RCAR_GEN2
There are 3 internal PCI controllers available with a single
built-in EHCI/OHCI host controller present on each one.
+config PCIE_KEYSTONE
+ bool "TI Keystone PCIe controller"
+ depends on ARCH_KEYSTONE
+ select PCIE_DW
+ select PCIEPORTBUS
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 13fb333..34e28c9 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
+obj-$(CONFIG_PCIE_KEYSTONE) += pcie-keystone.o k2-platform.o
diff --git a/drivers/pci/host/k2-platform.c b/drivers/pci/host/k2-platform.c
new file mode 100644
index 000..e10db00
--- /dev/null
+++ b/drivers/pci/host/k2-platform.c
@@ -0,0 +1,191 @@
+/*
+ * PCIe Keystone platform specific driver code
+ *
+ * Copyright (C) 2013-2014 Texas Instruments, Inc.
+ * http://www.ti.com
+ *
+ * Author: Murali Karicheri
+ *
+ * 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.
+
[RESEND: RFC PATCH 1/3] ARM: keystone: add pcie related options
Add pcie related options by default for keystone architecture CC: Jingoo Han CC: Bjorn Helgaas CC: Kukjin Kim CC: Richard Zhu CC: Shawn Guo CC: Mohit Kumar CC: Santosh Shilimkar Signed-off-by: Murali Karicheri --- arch/arm/mach-keystone/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig index 7e16d07..22c2174 100644 --- a/arch/arm/mach-keystone/Kconfig +++ b/arch/arm/mach-keystone/Kconfig @@ -17,6 +17,8 @@ config ARCH_KEYSTONE select TI_KEYSTONE select ARCH_SUPPORTS_BIG_ENDIAN select ZONE_DMA if ARM_LPAE + select MIGHT_HAVE_PCI + select ARCH_SUPPORTS_MSI help Support for boards based on the Texas Instruments Keystone family of SoCs. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] pci: designware: enhancements to support keystone pcie
keystone pcie hardware is based on designware hw version 3.65.
There is no support for ATU port and have registers in
application space to configure inbound/outbound access. Also
doesn't support PCI PVM option. So the MSI IRQ registers available
in application space is used to mask/unmask/enable the MSI IRQs.
This requires changes to designware core driver to support the
keystone pcie driver.
Also modified affected drivers to work with the APIs that
are modified for to keystone pcie driver.
CC: Jingoo Han
CC: Bjorn Helgaas
CC: Kukjin Kim
CC: Richard Zhu
CC: Shawn Guo
CC: Mohit Kumar
CC: Santosh Shilimkar
Signed-off-by: Murali Karicheri
---
drivers/pci/host/pci-exynos.c |2 +-
drivers/pci/host/pci-imx6.c|2 +-
drivers/pci/host/pcie-designware.c | 99
drivers/pci/host/pcie-designware.h | 14 -
4 files changed, 81 insertions(+), 36 deletions(-)
diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index 24beed3..3cae9b1 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -546,7 +546,7 @@ static int add_pcie_port(struct pcie_port *pp, struct
platform_device *pdev)
pp->ops = _pcie_host_ops;
spin_lock_init(>conf_lock);
- ret = dw_pcie_host_init(pp);
+ ret = dw_pcie_host_init(pp, NULL, NULL);
if (ret) {
dev_err(>dev, "failed to initialize host\n");
return ret;
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index bd70af8..0d77047 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -397,7 +397,7 @@ static int imx6_add_pcie_port(struct pcie_port *pp,
pp->ops = _pcie_host_ops;
spin_lock_init(>conf_lock);
- ret = dw_pcie_host_init(pp);
+ ret = dw_pcie_host_init(pp, NULL, NULL);
if (ret) {
dev_err(>dev, "failed to initialize host\n");
return ret;
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index e33b68b..02d4d25 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -248,11 +248,15 @@ static int assign_irq(int no_irqs, struct msi_desc *desc,
int *pos)
irq_alloc_descs((irq + i), (irq + i), 1, 0);
irq_set_msi_desc(irq + i, desc);
/*Enable corresponding interrupt in MSI interrupt controller */
- res = ((pos0 + i) / 32) * 12;
- bit = (pos0 + i) % 32;
- dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, );
- val |= 1 << bit;
- dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, val);
+ if (!(pp->version & DW_VERSION_PRE_3_70)) {
+ res = ((pos0 + i) / 32) * 12;
+ bit = (pos0 + i) % 32;
+ dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
+4, );
+ val |= 1 << bit;
+ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
+4, val);
+ }
i++;
}
@@ -288,11 +292,13 @@ static void clear_irq(unsigned int irq)
clear_bit(pos, pp->msi_irq_in_use);
/* Disable corresponding interrupt on MSI interrupt controller */
- res = (pos / 32) * 12;
- bit = pos % 32;
- dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, );
- val &= ~(1 << bit);
- dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, val);
+ if (!(pp->version & DW_VERSION_PRE_3_70)) {
+ res = (pos / 32) * 12;
+ bit = pos % 32;
+ dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, );
+ val &= ~(1 << bit);
+ dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, val);
+ }
}
static int dw_msi_setup_irq(struct msi_chip *chip, struct pci_dev *pdev,
@@ -326,7 +332,10 @@ static int dw_msi_setup_irq(struct msi_chip *chip, struct
pci_dev *pdev,
msg_ctr);
desc->msi_attrib.multiple = msgvec;
- msg.address_lo = virt_to_phys((void *)pp->msi_data);
+ if (pp->ops->get_msi_data)
+ msg.address_lo = pp->ops->get_msi_data(pp);
+ else
+ msg.address_lo = virt_to_phys((void *)pp->msi_data);
msg.address_hi = 0x0;
msg.data = pos;
write_msi_msg(irq, );
@@ -366,14 +375,27 @@ static const struct irq_domain_ops msi_domain_ops = {
.map = dw_pcie_msi_map,
};
-int __init dw_pcie_host_init(struct pcie_port *pp)
+int __init dw_pcie_host_init(struct pcie_port *pp, struct hw_pci *hw,
+ const struct irq_domain_ops *irq_ops)
{
struct device_node *np = pp->dev->of_node;
- struct of_pci_range range;
+ const struct irq_domain_ops
[PATCH 1/3] ARM: keystone: add pcie related options
Add pcie related options by default for keystone architecture CC: Jingoo Han CC: Bjorn Helgaas CC: Kukjin Kim CC: Richard Zhu CC: Shawn Guo CC: Mohit Kumar CC: Santosh Shilimkar Signed-off-by: Murali Karicheri --- arch/arm/mach-keystone/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig index 7e16d07..22c2174 100644 --- a/arch/arm/mach-keystone/Kconfig +++ b/arch/arm/mach-keystone/Kconfig @@ -17,6 +17,8 @@ config ARCH_KEYSTONE select TI_KEYSTONE select ARCH_SUPPORTS_BIG_ENDIAN select ZONE_DMA if ARM_LPAE + select MIGHT_HAVE_PCI + select ARCH_SUPPORTS_MSI help Support for boards based on the Texas Instruments Keystone family of SoCs. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/3] Add Keystone pcie driver
This is a RFC to add Keystone pcie driver. I had some earlier discussion on the pcie mailing about this driver and at that time I didn't have the driver ported to dw core driver. I now have a driver working with intel's e1000e ethernet driver and want to review this RFC on this list. Kestone PCIE hardware is based on dw version 3.65. It lacks ATU port and standard MSI controller found in newer version of the dw hardware. This version uses registers in PCIE application space to configure MSI controller. It has 4 host irqs for legacy IRQs A/B/C/D and 8 host irqs to muliplex 32 MSI irqs. Also has one host irq line for errors. Please review and provide your comments. CC: Jingoo Han CC: Bjorn Helgaas CC: Kukjin Kim CC: Richard Zhu CC: Shawn Guo CC: Mohit Kumar CC: Santosh Shilimkar Murali Karicheri (3): ARM: keystone: add pcie related options pci: designware: enhancements to support keystone pcie pcie: keystone: add pcie driver based on designware core driver .../devicetree/bindings/pci/pcie-keystone.txt | 32 + arch/arm/mach-keystone/Kconfig |2 + drivers/pci/host/Kconfig |5 + drivers/pci/host/Makefile |1 + drivers/pci/host/k2-platform.c | 191 + drivers/pci/host/pci-exynos.c |2 +- drivers/pci/host/pci-imx6.c|2 +- drivers/pci/host/pcie-designware.c | 99 ++- drivers/pci/host/pcie-designware.h | 14 +- drivers/pci/host/pcie-keystone.c | 860 drivers/pci/host/pcie-ks-pdata.h | 19 + drivers/pci/quirks.c | 12 + 12 files changed, 1203 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/pcie-keystone.txt create mode 100644 drivers/pci/host/k2-platform.c create mode 100644 drivers/pci/host/pcie-keystone.c create mode 100644 drivers/pci/host/pcie-ks-pdata.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] pcie: keystone: add pcie driver based on designware core driver
keystone pcie hardware is based on designware version 3.65. This
doesn't support standard MSI controller and ATU port available
on newer version of the designware hardware. In keystone dw hardware
the application register space implements the legacy and MSI
irq controller registers and has registers to allow outbound and
inbound translations. So the outbound/inbound configuration is
done by the keystone pcie driver.
Driver needs to handle irq as there are EOI registers available to
ack the interrupt after the same is acked by the end point device
driver. This requires irqchip implementation for legacy and MSI
irq handling. The driver however re-uses functions from dw core
wherever possible by making their prototype available in the dw
header file and calling the same from the keystone pcie driver.
Also add dts binding documentation for configuration details.
CC: Jingoo Han
CC: Bjorn Helgaas
CC: Kukjin Kim
CC: Richard Zhu
CC: Shawn Guo
CC: Mohit Kumar
CC: Santosh Shilimkar
Signed-off-by: Murali Karicheri
---
.../devicetree/bindings/pci/pcie-keystone.txt | 32 +
drivers/pci/host/Kconfig |5 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/k2-platform.c | 191 +
drivers/pci/host/pcie-keystone.c | 860
drivers/pci/host/pcie-ks-pdata.h | 19 +
drivers/pci/quirks.c | 12 +
7 files changed, 1120 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/pcie-keystone.txt
create mode 100644 drivers/pci/host/k2-platform.c
create mode 100644 drivers/pci/host/pcie-keystone.c
create mode 100644 drivers/pci/host/pcie-ks-pdata.h
diff --git a/Documentation/devicetree/bindings/pci/pcie-keystone.txt
b/Documentation/devicetree/bindings/pci/pcie-keystone.txt
new file mode 100644
index 000..b7b7651
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pcie-keystone.txt
@@ -0,0 +1,32 @@
+Keystone PCIE Root complex device tree bindings
+---
+
+Sample bindings shown below:-
+
+ - Remove enable-linktrain if boot loader already does Link training and do EP
+ configuration.
+ - To Disable SERDES initialization during Linux boot up, remove the
"reg_serdes"
+ reg values from the reg property.
+
+ pcie@2180 {
+ compatible = "ti,keystone2-pcie";
+ device_type = "pci";
+ clocks = <>;
+ clock-names = "pcie";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ reg = <0x2180 0x1000>, <0x0262014c 4>, <0x0232 0x4000>;
+ reg-names = "reg_rc_app", "reg_devcfg", "reg_serdes";
+ interrupts =<0 26 0xf01>, <0 27 0xf01>, <0 28 0xf01>, <0 29
0xf01>,
+ <0 30 0xf01>, <0 31 0xf01>, <0 32 0xf01>, <0 33
0xf01>,
+ <0 34 0xf01>, <0 35 0xf01>, <0 36 0xf01>, <0 37
0xf01>,
+ <0 38 0xf01>; /* Error IRQ */
+
+ ranges = <0x0800 0 0x21801000 0x21801000 0 0x0002000 /*
Configuration space */
+ 0x8100 0 0 0x2400 0 0x4000 /*
downstream I/O */
+ 0x8200 0 0x5000 0x5000 0 0x1000>; /*
non-prefetchable memory */
+
+ num-lanes = <2>;
+ ti,enable-linktrain;
+ };
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 47d46c6..9e45260 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -33,4 +33,9 @@ config PCI_RCAR_GEN2
There are 3 internal PCI controllers available with a single
built-in EHCI/OHCI host controller present on each one.
+config PCIE_KEYSTONE
+ bool "TI Keystone PCIe controller"
+ depends on ARCH_KEYSTONE
+ select PCIE_DW
+ select PCIEPORTBUS
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 13fb333..34e28c9 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
+obj-$(CONFIG_PCIE_KEYSTONE) += pcie-keystone.o k2-platform.o
diff --git a/drivers/pci/host/k2-platform.c b/drivers/pci/host/k2-platform.c
new file mode 100644
index 000..e10db00
--- /dev/null
+++ b/drivers/pci/host/k2-platform.c
@@ -0,0 +1,191 @@
+/*
+ * PCIe Keystone platform specific driver code
+ *
+ * Copyright (C) 2013-2014 Texas Instruments, Inc.
+ * http://www.ti.com
+ *
+ * Author: Murali Karicheri
+ *
+ * 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.
+
[PATCH 2/2] staging: binder: reduce line size
Signed-off-by: Mathieu Maret
---
drivers/staging/android/binder.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
index 9418086..4e51034 100644
--- a/drivers/staging/android/binder.c
+++ b/drivers/staging/android/binder.c
@@ -2688,7 +2688,8 @@ static long binder_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
ret = -EINVAL;
goto err;
}
- if (put_user(BINDER_CURRENT_PROTOCOL_VERSION, &((struct
binder_version __user *)ubuf)->protocol_version)) {
+ if (put_user(BINDER_CURRENT_PROTOCOL_VERSION,
+ &((struct binder_version __user
*)ubuf)->protocol_version)) {
ret = -EINVAL;
goto err;
}
--
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] staging: binder: add __user annotation in binder.c
Fix the following spare warning
drivers/staging/android/binder.c:2691:21: warning: incorrect type in argument 1
(different address spaces)
Signed-off-by: Mathieu Maret
---
drivers/staging/android/binder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
index cfe4bc8..9418086 100644
--- a/drivers/staging/android/binder.c
+++ b/drivers/staging/android/binder.c
@@ -2688,7 +2688,7 @@ static long binder_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
ret = -EINVAL;
goto err;
}
- if (put_user(BINDER_CURRENT_PROTOCOL_VERSION, &((struct
binder_version *)ubuf)->protocol_version)) {
+ if (put_user(BINDER_CURRENT_PROTOCOL_VERSION, &((struct
binder_version __user *)ubuf)->protocol_version)) {
ret = -EINVAL;
goto err;
}
--
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: [PATCH 14/16] backlight: atmel-pwm-bl: remove obsolete driver
On Tuesday, March 25, 2014 12:54 AM, Alexandre Belloni wrote: > On 21/03/2014 at 09:51:16 +0900, Jingoo Han wrote : > > On Wednesday, March 19, 2014 11:23 PM, Hans-Christian Egtvedt wrote: > > > Around Wed 19 Mar 2014 14:03:27 +0100 or thereabout, Alexandre Belloni > > > wrote: > > > > The atmel-pwm-bl driver is now obsolete. It is not used by any > > > > mainlined boards > > > > and is replaced by the generic pwm_bl with the pawm-atmel driver using > > > > the > > > > generic PWM framework. > > > > > > > > Signed-off-by: Alexandre Belloni > > > > > > Acked-by: Hans-Christian Egtvedt > > > > Acked-by: Jingoo Han > > > > You didn't comment on patch 08/16, are you fine with it ? I guess this > is the only one holding back the full series. 'drivers/video/backlight/pwm_bl.c' is Thierry Reding's domain, as follows. PWM SUBSYSTEM M: Thierry Reding L: linux-...@vger.kernel.org S: Maintained . F: drivers/video/backlight/pwm_bl.c So, it is required to get Ack from Thierry Reding. Best regards, Jingoo Han > > Regards, > > -- > Alexandre Belloni, 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/2] clk: s2mps11: Fix possible NULL pointer dereference
Quoting Krzysztof Kozlowski (2014-03-21 05:18:17)
> If parent device does not have of_node set the s2mps11_clk_parse_dt()
> returned NULL. This NULL was later passed to of_clk_add_provider() which
> dereferenced it in pr_debug() call.
>
> Signed-off-by: Krzysztof Kozlowski
I've taken both of these patches into clk-next.
Thanks!
Mike
> Cc:
> ---
> drivers/clk/clk-s2mps11.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
> index 00a3abe103a5..27c83e45eaed 100644
> --- a/drivers/clk/clk-s2mps11.c
> +++ b/drivers/clk/clk-s2mps11.c
> @@ -130,7 +130,7 @@ static struct device_node *s2mps11_clk_parse_dt(struct
> platform_device *pdev)
> int i;
>
> if (!iodev->dev->of_node)
> - return NULL;
> + return ERR_PTR(-EINVAL);
>
> clk_np = of_find_node_by_name(iodev->dev->of_node, "clocks");
> if (!clk_np) {
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the keystone tree with the arm-soc tree
On Monday 24 March 2014 07:55 PM, Stephen Rothwell wrote:
> Hi Santosh,
>
> Today's linux-next merge of the keystone tree got a conflict in
> arch/arm/boot/dts/Makefile between commit ba5a37e52194 ("ARM: mvebu: Move
> kirkwood DT boards into mach-mvebu") from the arm-soc tree and commit
> 400550ae7e77 ("ARM: dts: Build all keystone dt blobs") from the keystone
> tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
Looks fine. Thanks
Regards,
Santosh
--
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 net-next v3 3/3] xen-netback: Functional follow-up patch for grant mapping series
Ian made some late comments about the grant mapping series, I incorporated the
functional outcomes into this patch:
- use callback_param macro to shorten access to pending_tx_info in
xenvif_fill_frags() and xenvif_tx_submit()
- print an error message in xenvif_idx_unmap() before panic
Signed-off-by: Zoltan Kiss
---
v2:
- expand commit message and split this into 2 patch
- fix typos
v3: change the subject
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index f5c440b..0efa32d 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -99,6 +99,9 @@ static inline unsigned long idx_to_kaddr(struct xenvif *vif,
return (unsigned long)pfn_to_kaddr(idx_to_pfn(vif, idx));
}
+#define callback_param(vif, pending_idx) \
+ (vif->pending_tx_info[pending_idx].callback_struct)
+
/* Find the containing VIF's structure from a pointer in pending_tx_info array
*/
static inline struct xenvif* ubuf_to_vif(struct ubuf_info *ubuf)
@@ -1020,12 +1023,12 @@ static void xenvif_fill_frags(struct xenvif *vif,
struct sk_buff *skb)
/* If this is not the first frag, chain it to the previous*/
if (unlikely(prev_pending_idx == INVALID_PENDING_IDX))
skb_shinfo(skb)->destructor_arg =
-
>pending_tx_info[pending_idx].callback_struct;
+ _param(vif, pending_idx);
else if (likely(pending_idx != prev_pending_idx))
-
vif->pending_tx_info[prev_pending_idx].callback_struct.ctx =
-
&(vif->pending_tx_info[pending_idx].callback_struct);
+ callback_param(vif, prev_pending_idx).ctx =
+ _param(vif, pending_idx);
- vif->pending_tx_info[pending_idx].callback_struct.ctx = NULL;
+ callback_param(vif, pending_idx).ctx = NULL;
prev_pending_idx = pending_idx;
txp = >pending_tx_info[pending_idx].req;
@@ -1395,13 +1398,13 @@ static int xenvif_tx_submit(struct xenvif *vif)
memcpy(skb->data,
(void *)(idx_to_kaddr(vif, pending_idx)|txp->offset),
data_len);
- vif->pending_tx_info[pending_idx].callback_struct.ctx = NULL;
+ callback_param(vif, pending_idx).ctx = NULL;
if (data_len < txp->size) {
/* Append the packet payload as a fragment. */
txp->offset += data_len;
txp->size -= data_len;
skb_shinfo(skb)->destructor_arg =
-
>pending_tx_info[pending_idx].callback_struct;
+ _param(vif, pending_idx);
} else {
/* Schedule a response immediately. */
xenvif_idx_unmap(vif, pending_idx);
@@ -1678,11 +1680,20 @@ void xenvif_idx_unmap(struct xenvif *vif, u16
pending_idx)
idx_to_kaddr(vif, pending_idx),
GNTMAP_host_map,
vif->grant_tx_handle[pending_idx]);
xenvif_grant_handle_reset(vif, pending_idx);
ret = gnttab_unmap_refs(_unmap_op, NULL,
>mmap_pages[pending_idx], 1);
- BUG_ON(ret);
+ if (ret) {
+ netdev_err(vif->dev,
+ "Unmap fail: ret: %d pending_idx: %d host_addr: %llx
handle: %x status: %d\n",
+ ret,
+ pending_idx,
+ tx_unmap_op.host_addr,
+ tx_unmap_op.handle,
+ tx_unmap_op.status);
+ BUG();
+ }
xenvif_idx_release(vif, pending_idx, XEN_NETIF_RSP_OKAY);
}
--
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 net-next v3 2/3] xen-netback: Non-functional follow-up patch for grant mapping series
Ian made some late comments about the grant mapping series, I incorporated the
non-functional outcomes into this patch:
- typo fixes in a comment of xenvif_free(), and add another one there as well
- typo fix for comment of rx_drain_timeout_msecs
- remove stale comment before calling xenvif_grant_handle_reset()
Signed-off-by: Zoltan Kiss
---
v2:
- expand commit message and split this into 2 patch
- fix typos
v3: Change the subject
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index e71fb1a..cdc298e 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -574,15 +574,15 @@ void xenvif_disconnect(struct xenvif *vif)
void xenvif_free(struct xenvif *vif)
{
int i, unmap_timeout = 0;
- /* Here we want to avoid timeout messages if an skb can be legitimatly
-* stucked somewhere else. Realisticly this could be an another vif's
+ /* Here we want to avoid timeout messages if an skb can be legitimately
+* stuck somewhere else. Realistically this could be an another vif's
* internal or QDisc queue. That another vif also has this
* rx_drain_timeout_msecs timeout, but the timer only ditches the
* internal queue. After that, the QDisc queue can put in worst case
* XEN_NETIF_RX_RING_SIZE / MAX_SKB_FRAGS skbs into that another vif's
* internal queue, so we need several rounds of such timeouts until we
* can be sure that no another vif should have skb's from us. We are
-* not sending more skb's, so newly stucked packets are not interesting
+* not sending more skb's, so newly stuck packets are not interesting
* for us here.
*/
unsigned int worst_case_skb_lifetime = (rx_drain_timeout_msecs/1000) *
@@ -597,6 +597,13 @@ void xenvif_free(struct xenvif *vif)
netdev_err(vif->dev,
"Page still granted! Index: %x\n",
i);
+ /* If there are still unmapped pages, reset the loop to
+* start checking again. We shouldn't exit here until
+* dealloc thread and NAPI instance release all the
+* pages. If a kernel bug causes the skbs to stall
+* somewhere, the interface cannot be brought down
+* properly.
+*/
i = -1;
}
}
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index f5c440b..684c10b 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -56,7 +56,7 @@ bool separate_tx_rx_irq = 1;
module_param(separate_tx_rx_irq, bool, 0644);
/* When guest ring is filled up, qdisc queues the packets for us, but we have
- * to timeout them, otherwise other guests' packets can get stucked there
+ * to timeout them, otherwise other guests' packets can get stuck there
*/
unsigned int rx_drain_timeout_msecs = 1;
module_param(rx_drain_timeout_msecs, uint, 0444);
@@ -1545,7 +1545,6 @@ static inline void xenvif_tx_dealloc_action(struct xenvif
*vif)
idx_to_kaddr(vif, pending_idx),
GNTMAP_host_map,
vif->grant_tx_handle[pending_idx]);
- /* Btw. already unmapped? */
xenvif_grant_handle_reset(vif, pending_idx);
++gop;
}
@@ -1678,7 +1677,6 @@ void xenvif_idx_unmap(struct xenvif *vif, u16 pending_idx)
idx_to_kaddr(vif, pending_idx),
GNTMAP_host_map,
vif->grant_tx_handle[pending_idx]);
- /* Btw. already unmapped? */
xenvif_grant_handle_reset(vif, pending_idx);
ret = gnttab_unmap_refs(_unmap_op, NULL,
--
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 net-next v3 1/3] xen-netback: Stop using xenvif_tx_pending_slots_available
Since the early days TX stops if there isn't enough free pending slots to
consume a maximum sized (slot-wise) packet. Probably the reason for that is to
avoid the case when we don't have enough free pending slot in the ring to finish
the packet. But if we make sure that the pending ring has the same size as the
shared ring, that shouldn't really happen. The frontend can only post packets
which fit the to the free space of the shared ring. If it doesn't, the frontend
has to stop, as it can only increase the req_prod when the whole packet fits
onto the ring.
This patch avoid using this checking, makes sure the 2 ring has the same size,
and remove a checking from the callback. As now we don't stop the NAPI instance
on this condition, we don't have to wake it up if we free pending slots up.
Signed-off-by: Zoltan Kiss
---
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index bef37be..a800a8e 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -81,7 +81,7 @@ struct xenvif_rx_meta {
#define MAX_BUFFER_OFFSET PAGE_SIZE
-#define MAX_PENDING_REQS 256
+#define MAX_PENDING_REQS XEN_NETIF_TX_RING_SIZE
/* It's possible for an skb to have a maximal number of frags
* but still be less than MAX_BUFFER_OFFSET in size. Thus the
@@ -253,12 +253,6 @@ static inline pending_ring_idx_t nr_pending_reqs(struct
xenvif *vif)
vif->pending_prod + vif->pending_cons;
}
-static inline bool xenvif_tx_pending_slots_available(struct xenvif *vif)
-{
- return nr_pending_reqs(vif) + XEN_NETBK_LEGACY_SLOTS_MAX
- < MAX_PENDING_REQS;
-}
-
/* Callback from stack when TX packet can be released */
void xenvif_zerocopy_callback(struct ubuf_info *ubuf, bool zerocopy_success);
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 83a71ac..7bb7734 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -88,8 +88,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
local_irq_save(flags);
RING_FINAL_CHECK_FOR_REQUESTS(>tx, more_to_do);
- if (!(more_to_do &&
- xenvif_tx_pending_slots_available(vif)))
+ if (!more_to_do)
__napi_complete(napi);
local_irq_restore(flags);
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index bc94320..5df8d63 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1175,8 +1175,7 @@ static unsigned xenvif_tx_build_gops(struct xenvif *vif,
int budget)
struct sk_buff *skb;
int ret;
- while (xenvif_tx_pending_slots_available(vif) &&
- (skb_queue_len(>tx_queue) < budget)) {
+ while (skb_queue_len(>tx_queue) < budget) {
struct xen_netif_tx_request txreq;
struct xen_netif_tx_request txfrags[XEN_NETBK_LEGACY_SLOTS_MAX];
struct xen_netif_extra_info extras[XEN_NETIF_EXTRA_TYPE_MAX-1];
@@ -1516,13 +1515,6 @@ void xenvif_zerocopy_callback(struct ubuf_info *ubuf,
bool zerocopy_success)
wake_up(>dealloc_wq);
spin_unlock_irqrestore(>callback_lock, flags);
- if (RING_HAS_UNCONSUMED_REQUESTS(>tx) &&
- xenvif_tx_pending_slots_available(vif)) {
- local_bh_disable();
- napi_schedule(>napi);
- local_bh_enable();
- }
-
if (likely(zerocopy_success))
vif->tx_zerocopy_success++;
else
@@ -1714,8 +1706,7 @@ static inline int rx_work_todo(struct xenvif *vif)
static inline int tx_work_todo(struct xenvif *vif)
{
- if (likely(RING_HAS_UNCONSUMED_REQUESTS(>tx)) &&
- xenvif_tx_pending_slots_available(vif))
+ if (likely(RING_HAS_UNCONSUMED_REQUESTS(>tx)))
return 1;
return 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/
linux-next: manual merge of the keystone tree with the arm-soc tree
Hi Santosh,
Today's linux-next merge of the keystone tree got a conflict in
arch/arm/boot/dts/Makefile between commit ba5a37e52194 ("ARM: mvebu: Move
kirkwood DT boards into mach-mvebu") from the arm-soc tree and commit
400550ae7e77 ("ARM: dts: Build all keystone dt blobs") from the keystone
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/boot/dts/Makefile
index 94939ee0c10b,49ff796dc02e..
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@@ -82,9 -81,11 +82,12 @@@ dtb-$(CONFIG_ARCH_HIGHBANK) += highbank
ecx-2000.dtb
dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
integratorcp.dtb
+ dtb-$(CONFIG_ARCH_KEYSTONE) += k2hk-evm.dtb \
+ k2l-evm.dtb \
+ k2e-evm.dtb
-dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
-dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
+kirkwood := \
+ kirkwood-b3.dtb \
+ kirkwood-cloudbox.dtb \
kirkwood-db-88f6281.dtb \
kirkwood-db-88f6282.dtb \
kirkwood-dns320.dtb \
pgpC2TCNxLJdd.pgp
Description: PGP signature
Re: [PATCH net-next 1/7] altera: Remove casts of pointer to same type
Hi Joe, thanks for the patch. On Mon, Mar 24, 2014 at 3:15 PM, Joe Perches wrote: > Casting a pointer to a pointer of the same type is pointless, > so remove these unnecessary casts. > > Done via coccinelle script: > > $ cat typecast_2.cocci > @@ > type T; > T *foo; > @@ > > - (T *)foo > + foo > > Signed-off-by: Joe Perches > --- Acked-by: Vince Bridgers All the best, Vince -- 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 RFC 0/3] tcp: allow to repair a tcp connections in closing states
From: Andrey Vagin Date: Fri, 21 Mar 2014 17:32:58 +0400 > Currently connections only in the TCP_ESTABLISHED state can be dumped and > restored. This series allows to restore connections in the FIN_WAIT_1, > FIN_WAIT_2, LAST_ACK, CLOSE_WAIT or CLOSING states. > > For restoring closing states we need an ability to restore a fin packet > in a queue. In this series I suggest to use the interface of control > messages for that. I see no real value in this unless you tackle TIME_WAIT as well, and that's going to add so much code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: rockchip: fix offset of mux registers for rk3188
Am Montag, 24. März 2014, 23:36:01 schrieb Beniamino Galvani:
> The correct value of .mux_offset for rk3188 seems to be 0x60
> instead of 0x68.
Executive summary: the offset-change itself is correct, therefore
Reviewed-by: Heiko Stuebner
That is what one gets when the only source is a vendor tree.
I've looked it up again, and it seems you're right with the offset, but there
seems to be more to it ;-)
GPIO0 only has the second two IOMUX registers:
- GRF_GPIO0C_IOMUX at 0x68
- GRF_GPIO0D_IOMUX at 0x6c
which I guess is where my mistake comes from.
It looks like there does no iomux register exist at all for the first 16 pins.
In any case, the current number is wrong, and the 0x60 offset is the correct
one, but I guess we need to determine what the affected pins do - do they
always have a gpio mux or such?
Thanks for catching the mistake.
Heiko
> Signed-off-by: Beniamino Galvani
> ---
> drivers/pinctrl/pinctrl-rockchip.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> b/drivers/pinctrl/pinctrl-rockchip.c index 46dddc1..23e8812 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
> @@ -1534,7 +1534,7 @@ static struct rockchip_pin_ctrl rk3188_pin_ctrl = {
> .nr_banks = ARRAY_SIZE(rk3188_pin_banks),
> .label = "RK3188-GPIO",
> .type = RK3188,
> - .mux_offset = 0x68,
> + .mux_offset = 0x60,
> .pull_calc_reg = rk3188_calc_pull_reg_and_bit,
> };
--
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] staging/usbip: fix store_attach() sscanf return value check
Fix commit - 88fa1ebfa21b5deaaad2dc88ecd9f6af91796cf7
This commit added return value check for sscanf() that parses the
input buffer for four input items. However, the return value check
is incorrect, as it checks for one input item instead of four which
is what it is expecting in the input buffer. As a result, sscanf()
will always fail even when the input buffer is correct.
Signed-off-by: Shuah Khan
---
drivers/staging/usbip/vhci_sysfs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/usbip/vhci_sysfs.c
b/drivers/staging/usbip/vhci_sysfs.c
index e098032..1ff24e9 100644
--- a/drivers/staging/usbip/vhci_sysfs.c
+++ b/drivers/staging/usbip/vhci_sysfs.c
@@ -183,7 +183,7 @@ static ssize_t store_attach(struct device *dev, struct
device_attribute *attr,
* @devid: unique device identifier in a remote host
* @speed: usb device speed in a remote host
*/
- if (sscanf(buf, "%u %u %u %u", , , , ) != 1)
+ if (sscanf(buf, "%u %u %u %u", , , , ) != 4)
return -EINVAL;
usbip_dbg_vhci_sysfs("rhport(%u) sockfd(%u) devid(%u) speed(%u)\n",
--
1.7.10.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: 3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)
Hi, On Mon, Mar 24, 2014 at 10:46:49PM +0100, Daniel Vetter wrote: > On Mon, Mar 24, 2014 at 9:40 PM, Mikulas Patocka wrote: > > If someone understands the locking issues I pointed out above, it could be > > easy to fix. > > The locking issue isn't your problem, the real issue is that putting a > irq_uninstall into core code will break all the new (properly working) > drivers. And you can't really fix this in mga itself since the > lifetime rules of the register mappings are totally broken. It's a > fundamental misdesign of the legacy drm driver architecture and the > _only_ way to fix this bug for real is to rewrite this all. Which was > done for all the still used drivers like i915, radeon, nouveau, ... That sounds plausible - yet with meatballs (ok, maybe I should omit such quite possibly unjustified qualification) such as this: git show --stat 771fe6b912fca54f03 how is a bunch of marginally-trained hobbyists ever supposed to be implementing a working practical (i.e., "base") driver for *various* currently unsupported (booted would perhaps even be a more fitting word?) hardware? While the result of a wc -l check of the drivers/gpu/drm/r128 dir itself seems quite positive, that still might be not much of help when eyeing the large KMS changes that had to be done elsewhere. I guess we can make use of all the practical advice/links that we can get... (such as hints at good candidates of existing KMSified drivers which don't come with the full bells and whistles package, hints at suitably sized KMS support commits, grandma tutorials, ...). Some semi-short search wasn't overly successful, with links such as http://www.x.org/wiki/ModeSetting/ https://en.wikipedia.org/wiki/KMS_%28Linux_kernel%29#Linux "New, Generic X.Org KMS Driver Work" http://www.phoronix.com/scan.php?page=news_item=OTk1OA Or perhaps I should just state outright that I seem to be in need of a working solution for my kernel upgrade pain which I would be deemed to want semi-soonish (the i810, MGA users and some others might be sharing my thoughts). IOW, my r128 driver is somewhat of a "still used driver", thank you very much. Thanks for having managed to survive my posting in an asbestos-lined garment (apologies if it came across in harsh terms :), Andreas Mohr (not necessarily a member of the forced-monopoly hardware upgrade treadmill cult) -- 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 12/12] drm/nouveau: support for probing GK20A
On Mon, Mar 24, 2014 at 05:42:34PM +0900, Alexandre Courbot wrote: [...] > diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c > b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c [...] > + /* TODO will need an implementation for this at some point... */ Do we? If so the commit message in 11/12 is misleading. Thierry pgpmKt57hGeCR.pgp Description: PGP signature
Re: [PATCH 11/12] drm/nouveau: support GK20A in nouveau_accel_init()
On Mon, Mar 24, 2014 at 05:42:33PM +0900, Alexandre Courbot wrote:
> GK20A does not embed a dedicated COPY engine and thus cannot allocate
> the copy channel that nouveau_accel_init() attempts to create. It also
> lacks any display hardware, so the creation of a software channel does
> not apply neither.
Perhaps this should be two separate patches?
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
[...]
> + if (device->chipset == 0xea) {
> + /* gk20a does not have CE0/CE1 */
This would be another good candidate for a feature flag.
> + arg0 = NVE0_CHANNEL_IND_ENGINE_GR;
> + arg1 = 1;
> + } else
> if (device->card_type >= NV_E0) {
The formatting here is somewhat weird. From a brief look I couldn't find
any indication that nouveau deviates from the standard coding style, so
this should be:
} else if (...) {
> + /* Need to figure out how to handle sw for gk20a */
> + if (device->chipset == 0xea)
> + goto skip_sw_init;
The commit message makes it sound like SW isn't needed since gk20a
"lacks any display hardware". In that case the comment here doesn't make
much sense.
Thierry
pgpfHWIWCzz15.pgp
Description: PGP signature
Re: [PATCH 09/12] drm/nouveau/graph: pad firmware code at load time
On Mon, Mar 24, 2014 at 05:42:31PM +0900, Alexandre Courbot wrote: > Pad the microcode to a multiple of 0x40, otherwise firmware will fail to > run from non-prepadded firmware files. Perhaps this (and the comment in the code) should mention a unit. In this case it's 0x40 words. Also, I think using a decimal number would read easier here and in the comment. Furthermore, perhaps choosing a byte as the unit would be even more intuitive. But either way the code is correct, so: Reviewed-by: Thierry Reding pgpzdEum9AMqA.pgp Description: PGP signature
Re: [PATCH 2/2] ext4: acl: remove unneeded include of linux/capability.h
On Mon, Mar 24, 2014 at 08:22:12AM +0100, Jakub Sitnicki wrote:
> acl.c has not been (directly) using the interface defined by
> linux/capability.h header since commit 3bd858ab1c451725c07a
> ("Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid
> check"). Remove it.
>
> Signed-off-by: Jakub Sitnicki
Thanks, applied.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] vfs fixes
> [...] > Shortlog: > Al Viro (6): > make prepend_name() work correctly when called with negative *buflen A proper attribution for the above fix would have been nice. Tracking down the bug was the main thing after all: https://lkml.org/lkml/2014/3/12/620 --Imre -- 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] drm/nouveau/graph: enable when using external firmware
On Mon, Mar 24, 2014 at 05:42:30PM +0900, Alexandre Courbot wrote: [...] > diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c > b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c > index 6ef8bf181b2d..f997a18f5760 100644 > --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c > +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c > @@ -1133,10 +1133,14 @@ nvc0_graph_ctor(struct nouveau_object *parent, struct > nouveau_object *engine, > struct nvc0_graph_oclass *oclass = (void *)bclass; > struct nouveau_device *device = nv_device(parent); > struct nvc0_graph_priv *priv; > + bool use_fw; Perhaps "ext_fw" or "use_ext_fw" would be more accurate. > int ret, i; > > + use_fw = nouveau_boolopt(device->cfgopt, "NvGrUseFW", false); > + > ret = nouveau_graph_create(parent, engine, bclass, > -(oclass->fecs.ucode != NULL), ); > +(oclass->fecs.ucode != NULL) || use_fw, > +); Or perhaps a more intuitive way would be to name the variable "enable" and have something like: if (!nouveau_boolopt(device->cfgopt, "NvGrUseFW", false)) enable = oclass->fecs.ucode != NULL; else enable = true; ret = nouveau_graph_create(parent, engine, bclass, enable, ); ... Thierry pgpd58wSKBAft.pgp Description: PGP signature
[ANNOUNCE] 3.4.84-rt105
Dear RT Folks, I'm pleased to announce the 3.4.84-rt105 stable release. This release is just an update to the new stable 3.4.84 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.4-rt Head SHA1: ebbe3adc6986d0908248e6c45a7b186a4f7f8d92 Or to build 3.4.84-rt105 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.84.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.84-rt105.patch.xz Enjoy, -- Steve -- 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] staging: line6: Add blank lines after declarations
Use the more common kernel coding style.
Signed-off-by: Fabian Mewes
---
applies to next-20140324
v1..v2: improve commit message as suggested by Joe
drivers/staging/line6/driver.c | 1 +
drivers/staging/line6/playback.c | 5 +
drivers/staging/line6/toneport.c | 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 77f1b42..ef511c7 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -124,6 +124,7 @@ static int line6_send_raw_message_async_part(struct message
*msg,
static int line6_start_listen(struct usb_line6 *line6)
{
int err;
+
usb_fill_int_urb(line6->urb_listen, line6->usbdev,
usb_rcvintpipe(line6->usbdev, line6->ep_control_read),
line6->buffer_listen, LINE6_BUFSIZE_LISTEN,
diff --git a/drivers/staging/line6/playback.c b/drivers/staging/line6/playback.c
index 41869ca..0f72db5 100644
--- a/drivers/staging/line6/playback.c
+++ b/drivers/staging/line6/playback.c
@@ -34,6 +34,7 @@ static void change_volume(struct urb *urb_out, int volume[],
if (bytes_per_frame == 4) {
short *p, *buf_end;
+
p = (short *)urb_out->transfer_buffer;
buf_end = p + urb_out->transfer_buffer_length / sizeof(*p);
@@ -48,6 +49,7 @@ static void change_volume(struct urb *urb_out, int volume[],
for (; p < buf_end; p += 3) {
int val;
+
val = p[0] + (p[1] << 8) + ((signed char)p[2] << 16);
val = (val * volume[chn & 1]) >> 8;
p[0] = val;
@@ -116,6 +118,7 @@ static void add_monitor_signal(struct urb *urb_out,
unsigned char *signal,
if (bytes_per_frame == 4) {
short *pi, *po, *buf_end;
+
pi = (short *)signal;
po = (short *)urb_out->transfer_buffer;
buf_end = po + urb_out->transfer_buffer_length / sizeof(*po);
@@ -171,6 +174,7 @@ static int submit_audio_out_urb(struct snd_line6_pcm
*line6pcm)
if (fsize == 0) {
int n;
+
line6pcm->count_out += frame_increment;
n = line6pcm->count_out / frame_factor;
line6pcm->count_out -= n * frame_factor;
@@ -207,6 +211,7 @@ static int submit_audio_out_urb(struct snd_line6_pcm
*line6pcm)
copy the data to the temp buffer.
*/
int len;
+
len = runtime->buffer_size - line6pcm->pos_out;
if (len > 0) {
diff --git a/drivers/staging/line6/toneport.c b/drivers/staging/line6/toneport.c
index af2e7e5..dcab647 100644
--- a/drivers/staging/line6/toneport.c
+++ b/drivers/staging/line6/toneport.c
@@ -213,6 +213,7 @@ static int snd_toneport_source_info(struct snd_kcontrol
*kcontrol,
struct snd_ctl_elem_info *uinfo)
{
const int size = ARRAY_SIZE(toneport_source_info);
+
uinfo->type = SNDRV_CTL_ELEM_TYPE_ENUMERATED;
uinfo->count = 1;
uinfo->value.enumerated.items = size;
--
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: [PATCH 1/3] tcp: allow to enable repair mode for sockets in any state
> @@ -2375,7 +2378,7 @@ void tcp_sock_destruct(struct sock *sk)
> static inline bool tcp_can_repair_sock(const struct sock *sk)
> {
> return ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN) &&
> - ((1 << sk->sk_state) & (TCPF_CLOSE | TCPF_ESTABLISHED));
> + (sk->sk_state != TCP_LISTEN);
This set only covers states that may happen after ESTABLISHED, so
I would still exclude others (e.g. syn-sent) from the white list.
> }
>
> static int tcp_repair_options_est(struct tcp_sock *tp,
>
Thanks,
Pavel
--
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] pinctrl: rockchip: fix offset of mux registers for rk3188
The correct value of .mux_offset for rk3188 seems to be 0x60
instead of 0x68.
Signed-off-by: Beniamino Galvani
---
drivers/pinctrl/pinctrl-rockchip.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index 46dddc1..23e8812 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -1534,7 +1534,7 @@ static struct rockchip_pin_ctrl rk3188_pin_ctrl = {
.nr_banks = ARRAY_SIZE(rk3188_pin_banks),
.label = "RK3188-GPIO",
.type = RK3188,
- .mux_offset = 0x68,
+ .mux_offset = 0x60,
.pull_calc_reg = rk3188_calc_pull_reg_and_bit,
};
--
1.7.10.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 06/12] drm/nouveau/ibus: add GK20A support
On Mon, Mar 24, 2014 at 05:42:28PM +0900, Alexandre Courbot wrote:
[...]
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c
> b/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c
[...]
> +#include
> +
> +struct nvea_ibus_priv {
> + struct nouveau_ibus base;
> +};
> +
> +static void
> +nvea_ibus_init_priv_ring(struct nvea_ibus_priv *priv)
> +{
> + nv_mask(priv, 0x137250, 0x3f, 0);
> +
> + nv_mask(priv, 0x000200, 0x20, 0);
> + udelay(20);
usleep_range()?
> +static void
> +nvea_ibus_intr(struct nouveau_subdev *subdev)
> +{
[...]
> + /* Acknowledge interrupt */
> + nv_mask(priv, 0x12004c, 0x2, 0x2);
> +
> + while (--retry >= 0) {
> + command = nv_rd32(priv, 0x12004c) & 0x3f;
> + if (command == 0)
> + break;
> + }
> +
> + if (retry < 0)
> + nv_warn(priv, "timeout waiting for ringmaster ack\n");
> +}
Perhaps I'm being paranoid, but this loop now depends on the frequency
of the various clocks involved and therefore might break at some point
if the frequencies get sufficiently high.
So a slightly safer implementation would use a proper timeout using a
combination of msecs_to_jiffies(), time_before() and usleep_range(),
like so:
timeout = jiffies + msecs_to_jiffies(...);
while (time_before(jiffies, timeout)) {
command = nv_rd32(...) & 0x3f;
if (command == 0)
break;
usleep_range(...);
}
if (time_after(jiffies, timeout))
nv_warn(...);
This assumes that there's some known timeout after which the ringmaster
is expected to have acked the interrupt. On that note, I wonder if the
warning is accurate here: it's my understanding that writing 0x2 to the
register does acknowledge the interrupt, so the ringmaster does in fact
"clear" it rather than "acknowledge" it, doesn't it?
Although now that I mention it I seem to remember that this write is
actually sending a command to the ring master and perhaps waiting for
the register to return to 0 is indeed waiting for an ACK of sorts. Maybe
adding a comment or so describing what this sequence does would be
appropriate here?
Thierry
pgpR7NNijy_3i.pgp
Description: PGP signature
[ANNOUNCE] 3.10.34-rt34
Dear RT Folks, I'm pleased to announce the 3.10.34-rt34 stable release. This release is just an update to the new stable 3.10.34 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.10-rt Head SHA1: ff2826200b84358b9a9f1184710eb020088e8354 Or to build 3.10.34-rt34 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.10.34.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patch-3.10.34-rt34.patch.xz Enjoy, -- Steve -- 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 net-next 6/7] mwifiex: Remove casts of pointer to same type
Hi Joe,
Thanks for the patch.
> Casting a pointer to a pointer of the same type is pointless,
> so remove these unnecessary casts.
>
> Done via coccinelle script:
>
> $ cat typecast_2.cocci
> @@
> type T;
> T *foo;
> @@
>
> - (T *)foo
> + foo
>
> Signed-off-by: Joe Perches
Acked-by: Bing Zhao
Thanks,
Bing
> ---
> drivers/net/wireless/mwifiex/pcie.c | 6 +++---
> drivers/net/wireless/mwifiex/scan.c | 2 +-
> drivers/net/wireless/mwifiex/tdls.c | 6 +++---
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/mwifiex/pcie.c
> b/drivers/net/wireless/mwifiex/pcie.c
> index 9f1683b..c0c598d 100644
> --- a/drivers/net/wireless/mwifiex/pcie.c
> +++ b/drivers/net/wireless/mwifiex/pcie.c
> @@ -1009,7 +1009,7 @@ static int mwifiex_pcie_send_data_complete(struct
> mwifiex_adapter *adapter)
> card->tx_buf_list[wrdoneidx] = NULL;
>
> if (reg->pfu_enabled) {
> - desc2 = (void *)card->txbd_ring[wrdoneidx];
> + desc2 = card->txbd_ring[wrdoneidx];
> memset(desc2, 0, sizeof(*desc2));
> } else {
> desc = card->txbd_ring[wrdoneidx];
> @@ -1094,7 +1094,7 @@ mwifiex_pcie_send_data(struct mwifiex_adapter *adapter,
> struct sk_buff *skb,
> card->tx_buf_list[wrindx] = skb;
>
> if (reg->pfu_enabled) {
> - desc2 = (void *)card->txbd_ring[wrindx];
> + desc2 = card->txbd_ring[wrindx];
> desc2->paddr = buf_pa;
> desc2->len = (u16)skb->len;
> desc2->frag_len = (u16)skb->len;
> @@ -1254,7 +1254,7 @@ static int mwifiex_pcie_process_recv_data(struct
> mwifiex_adapter *adapter)
> card->rx_buf_list[rd_index] = skb_tmp;
>
> if (reg->pfu_enabled) {
> - desc2 = (void *)card->rxbd_ring[rd_index];
> + desc2 = card->rxbd_ring[rd_index];
> desc2->paddr = buf_pa;
> desc2->len = skb_tmp->len;
> desc2->frag_len = skb_tmp->len;
> diff --git a/drivers/net/wireless/mwifiex/scan.c
> b/drivers/net/wireless/mwifiex/scan.c
> index f139244..825aeec 100644
> --- a/drivers/net/wireless/mwifiex/scan.c
> +++ b/drivers/net/wireless/mwifiex/scan.c
> @@ -1653,7 +1653,7 @@ mwifiex_parse_single_response_buf(struct
> mwifiex_private *priv, u8 **bss_info,
> curr_bcn_bytes -= ETH_ALEN;
>
> if (!ext_scan) {
> - rssi = (s32) *(u8 *)current_ptr;
> + rssi = (s32) *current_ptr;
> rssi = (-rssi) * 100; /* Convert dBm to mBm */
> current_ptr += sizeof(u8);
> curr_bcn_bytes -= sizeof(u8);
> diff --git a/drivers/net/wireless/mwifiex/tdls.c
> b/drivers/net/wireless/mwifiex/tdls.c
> index 8cec6e4..97662a1 100644
> --- a/drivers/net/wireless/mwifiex/tdls.c
> +++ b/drivers/net/wireless/mwifiex/tdls.c
> @@ -730,13 +730,13 @@ void mwifiex_process_tdls_action_frame(struct
> mwifiex_private *priv,
>
> if (len < (sizeof(struct ethhdr) + 3))
> return;
> - if (*(u8 *)(buf + sizeof(struct ethhdr)) != WLAN_TDLS_SNAP_RFTYPE)
> + if (*(buf + sizeof(struct ethhdr)) != WLAN_TDLS_SNAP_RFTYPE)
> return;
> - if (*(u8 *)(buf + sizeof(struct ethhdr) + 1) != WLAN_CATEGORY_TDLS)
> + if (*(buf + sizeof(struct ethhdr) + 1) != WLAN_CATEGORY_TDLS)
> return;
>
> peer = buf + ETH_ALEN;
> - action = *(u8 *)(buf + sizeof(struct ethhdr) + 2);
> + action = *(buf + sizeof(struct ethhdr) + 2);
>
> /* just handle TDLS setup request/response/confirm */
> if (action > WLAN_TDLS_SETUP_CONFIRM)
> --
> 1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/12] drm/nouveau/fifo: add GK20A support
On Mon, Mar 24, 2014 at 05:42:27PM +0900, Alexandre Courbot wrote: > GK20A's FIFO is compatible with NVE0, but only features 128 channels and > 1 runlist. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/drm/nouveau/Makefile | 1 + > drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h| 1 + > drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c| 35 > ++ > drivers/gpu/drm/nouveau/core/include/engine/fifo.h | 1 + > 4 files changed, 38 insertions(+) > create mode 100644 drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c Looks good to me: Reviewed-by: Thierry Reding pgpnbuLOeQ5H_.pgp Description: PGP signature
Re: [PATCH 03/12] drm/nouveau/bar: only ioremap BAR3 if it exists
On Mon, Mar 24, 2014 at 05:42:25PM +0900, Alexandre Courbot wrote:
> Some chips that use system memory exclusively (e.g. GK20A) do not
> expose 2 BAR regions. For them only BAR1 exists, and it should be used
> for USERD mapping. Do not map BAR3 if its resource does not exist.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
> index bdf594116f3f..d713eeb75b13 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
> @@ -110,6 +110,7 @@ nouveau_bar_create_(struct nouveau_object *parent,
> {
> struct nouveau_device *device = nv_device(parent);
> struct nouveau_bar *bar;
> + bool has_bar3 = nv_device_resource_len(device, 3) != 0;
I don't think this variable is really necessary since you only use the
expression once anyway, but I don't feel very strongly about it, so
either way:
Reviewed-by: Thierry Reding
pgpdnMpy0dYnp.pgp
Description: PGP signature
Re: [PATCH 04/12] drm/nouveau/bar/nvc0: support chips without BAR3
On Mon, Mar 24, 2014 at 05:42:26PM +0900, Alexandre Courbot wrote:
[...]
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
> b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
[...]
> static int
> -nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
> - struct nouveau_oclass *oclass, void *data, u32 size,
> - struct nouveau_object **pobject)
> +nvc0_bar_init_vm(struct nvc0_bar_priv *priv, int nr, int bar)
> {
[...]
> - /* BAR3 */
> ret = nouveau_gpuobj_new(nv_object(priv), NULL, 0x1000, 0, 0,
> - >bar[0].mem);
> - mem = priv->bar[0].mem;
> + >bar[nr].mem);
> + mem = priv->bar[nr].mem;
> if (ret)
> return ret;
>
> ret = nouveau_gpuobj_new(nv_object(priv), NULL, 0x8000, 0, 0,
> - >bar[0].pgd);
> + >bar[nr].pgd);
> if (ret)
> return ret;
[...]
> +static int
> +nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
> + struct nouveau_oclass *oclass, void *data, u32 size,
> + struct nouveau_object **pobject)
> +{
[...]
> + /* BAR3 */
> + if (has_bar3) {
> + ret = nvc0_bar_init_vm(priv, 0, 3);
[...]
> + /* BAR1 */
> + ret = nvc0_bar_init_vm(priv, 1, 1);
> if (ret)
> return ret;
The calls to nvc0_bar_init_vm() are somewhat confusing in my opinion. It
is hard to see from the invocation what these numbers mean and therefore
distinguish which parameter is which.
Perhaps a slightly more readable way would be to pass in a pointer to a
structure as second parameter instead of the index into an array. So
it'd look somewhat like this:
if (has_bar3) {
ret = nvc0_bar_init_vm(priv, >bar[0], 3);
...
}
...
ret = nvc0_bar_init_vm(priv, >bar[1], 1);
...
Unfortunately that would require a new type to be created for the bar[]
structures, so it'd be slightly more intrusive.
Thierry
pgp4XK0OUHhJU.pgp
Description: PGP signature
Re: 3.14 radeon regression: radeon is broken (pci bug?)
On Sat, Mar 22, 2014 at 9:18 AM, Andy Lutomirski wrote: > On Fri, Mar 21, 2014 at 9:37 AM, Bjorn Helgaas wrote: >> On Fri, Mar 21, 2014 at 9:49 AM, Andy Lutomirski wrote: >>> On Fri, Mar 21, 2014 at 7:41 AM, Alex Deucher wrote: On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski wrote: > My system works on a 3.13 Fedora kernel. It does not work on a > more-or-less identically configured 3.14-rc7+ kernel. The symptom is > that the Plymouth password prompt flashes and them the screen goes > blank. Hitting escape brings back the text console, and all is well > until X tries to start. Then I get a blank screen. killall -9 Xorg > from ssh causes these errors to be logged: > > > [ 226.239747] [drm:atom_op_jump] *ERROR* atombios stuck in loop for > more than 5secs aborting > [ 226.239751] [drm:atom_execute_table_locked] *ERROR* atombios stuck > executing CD34 (len 55, WS 0, PS 0) @ 0xCD57 > [ 231.241492] [drm:atom_op_jump] *ERROR* atombios stuck in loop for > more than 5secs aborting > [ 231.241496] [drm:atom_execute_table_locked] *ERROR* atombios stuck > executing CD6C (len 62, WS 0, PS 0) @ 0xCD88 > [ 236.243111] [drm:atom_op_jump] *ERROR* atombios stuck in loop for > more than 5secs aborting > [ 236.243115] [drm:atom_execute_table_locked] *ERROR* atombios stuck > executing CD6C (len 62, WS 0, PS 0) @ 0xCD88 > [ 241.244625] [drm:atom_op_jump] *ERROR* atombios stuck in loop for > more than 5secs aborting > [ 241.244628] [drm:atom_execute_table_locked] *ERROR* atombios stuck > executing CD6C (len 62, WS 0, PS 0) @ 0xCD88 > > > lspci -vvvxxxnn on 3.14-rc7+ says: > > 09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. > [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779] > (rev ff) (prog-if ff) > !!! Unknown header type 7f > Kernel driver in use: radeon > 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > 09:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] > Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98] (rev ff) > (prog-if ff) > !!! Unknown header type 7f > Kernel driver in use: snd_hda_intel > 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > (oops!) > > On 3.13, it says: > > 09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. > [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779] > (prog-if 00 [VGA controller]) > Subsystem: PC Partner Limited / Sapphire Technology Radeon HD > 6450 1 GB DDR3 [174b:e164] > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 92 > Region 0: Memory at e000 (64-bit, prefetchable) [size=256M] > Region 2: Memory at f4a2 (64-bit, non-prefetchable) > [size=128K] > Region 4: I/O ports at c000 [size=256] > Expansion ROM at f4a0 [disabled] [size=128K] > Capabilities: > Kernel driver in use: radeon > 00: 02 10 79 67 07 04 10 00 00 00 00 03 10 00 80 00 > 10: 0c 00 00 e0 00 00 00 00 04 00 a2 f4 00 00 00 00 > 20: 01 c0 00 00 00 00 00 00 00 00 00 00 4b 17 64 e1 > 30: 00 00 a0 f4 50 00 00 00 00 00 00 00 0a 01 00 00 > > 09:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] > Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98] > Subsystem: PC Partner Limited / Sapphire Technology Radeon HD > 6450 1GB DDR3 [174b:aa98] > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin B routed to IRQ 96 > Region 0: Memory at f4a4 (64-bit, non-prefetchable) [size=16K] > Capabilities: > Kernel driver in use: snd_hda_intel > 00: 02 10 98 aa 06 04 10 00 00 00 03 04 10 00 80 00 > 10: 04 00 a4 f4 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 98 aa > 30: 00 00 00 00 50 00 00 00 00 00 00 00 05 02 00 00 > > Logs attached. >> >> Hi Andy, >> >> I'm really sorry that you tripped over this, but thanks a
Re: [RFC PATCH v2 0/2] clk: Support for DT assigned clock parents and rates
Quoting Maxime Coquelin (2014-03-21 07:09:26) > Hi Mike, > > On 03/21/2014 02:45 AM, Mike Turquette wrote: > > Quoting Sylwester Nawrocki (2014-03-20 05:42:33) > >> Hi Maxime, > >> > >> On 06/03/14 14:45, Maxime Coquelin wrote: > >>> Hi Sylwester, > >>> > >>>I like the principle of your implementation, but I have two > >>> questions: > >>>1 - How can we manage PM with this solution, as the parent/rate > >>> will be > >>> set only once at probe time? > >>>2 - How to set the parent of a parent clock (which can be shared > >>> with > >>> other devices)? Same question about the parent rates. > >> > >> Thanks for your feedback and apologies for late reply. > >> > >> IIUC your first concern is about a situation when clocks need to be > >> reconfigured upon each resume from system sleep or runtime PM resume ? > >> As I mentioned in v1 of the RFC I was considering having individual > >> drivers calling explicitly the clocks set up routine. Presumably this > >> would allow to resolve the power management related issue. > >> One example I'm aware the approach as in this RFC wouldn't work is > >> when a device in a SoC belongs to a power domain, which needs to be > >> first switched on before we can start setting up and the clocks' > >> configuration get lost after the power domain switch off. > > > > I like Sylwester's approach of handling this one-time setup in the > > driver core. > > > > Any kind of fine grained power management should not be hidden by DT, > > and by definition that logic belongs in the device driver. It can still > > be nicely abstracted away by runtime pm[1]. > > > > Regards, > > Mike > > > > [1] Message-ID: <20140320114238.gq7...@n2100.arm.linux.org.uk> > How can I access this reference? I was trying to provide a reference to this thread which is tangentially related to this topic: http://www.spinics.net/lists/arm-kernel/msg317016.html But it hadn't hit any of the mail archives at the time of my writing so I just copied Russell's Message-ID from his email. If you have a copy of that email then you can search on Message-ID's for that and you will find it. :-) Regards, Mike > > Thanks, > Maxime > > > > >> > >> OTOH I suspect devices for which one-time clocks setup is sufficient > >> will be quite common. And for these there would need to be a single > >> call to the setup routine in probe() I guess, since it wouldn't be > >> possible to figure out just from the DT data when the actual call > >> should be made. > >> > >> For a global clocks configuration, I thought about specifying that > >> in the clocks controller node, and then to have the setup routine > >> called e.g. from of_clk_init(). I think that could work well enough, > >> together with the patch [1], adding clock dependencies handling. > >> But then the clock frequency set up function would need to be > >> modified to respect the clock parent relationships, similarly as > >> in patch series [2]. A just noticed [2] recently, after posting > >> this RFC (adding Tero at Cc). > >> > >> -- > >> Regards, > >> Sylwester > >> > >> [1] http://www.spinics.net/lists/arm-kernel/msg310507.html > >> [2] http://www.spinics.net/lists/linux-omap/msg103069.html -- 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 02/12] drm/nouveau/timer: skip calibration on GK20A
On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote: > GK20A's timer is directly attached to the system timer and cannot be > calibrated. Skip the calibration phase on that chip since the > corresponding registers do not exist. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 19 +-- > 1 file changed, 13 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c > b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c > index c0bdd10358d7..822fe0d8a871 100644 > --- a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c > +++ b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c > @@ -185,6 +185,10 @@ nv04_timer_init(struct nouveau_object *object) > if (ret) > return ret; > > + /* gk20a does not have the calibration registers */ > + if (device->chipset == 0xea) > + goto skip_clk_init; I'm concerned that this won't scale in the future. Perhaps a better solution would be to add a "flags" or "features" field to struct nouveau_device along with feature bits such as HAS_CALIBRATION or similar. That way we don't have to touch this code for every new future Tegra chip. Unless perhaps if there's a reason to expect things to change in newer generations. Thierry pgp92qd4K0_Q2.pgp Description: PGP signature
[PATCH 1/1] fs/ext4/ioctl.c: Remove unused macro MAX_32_NUM
01f795f9e0d67a
("ext4: add online resizing support for meta_bg and 64-bit file systems")
removed the last use of MAX_32_NUM
Signed-off-by: Fabian Frederick
---
fs/ext4/ioctl.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index a2a837f..ea5dace 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -18,8 +18,6 @@
#include "ext4_jbd2.h"
#include "ext4.h"
-#define MAX_32_NUM unsigned long long) 1) << 32) - 1)
-
/**
* Swap memory between @a and @b for @len bytes.
*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/7] clk: sunxi: Remove calls to clk_put
Quoting Maxime Ripard (2014-03-13 08:14:13)
> Callers of clk_put must disable the clock first. This also means that as long
> as the clock is enabled the driver should hold a reference to that clock.
> Hence, the call to clk_put here are bogus and should be removed.
>
> Signed-off-by: Maxime Ripard
Looks good to me. There is a balanced clk_put in the module remove
function?
Regards,
Mike
> ---
> drivers/clk/sunxi/clk-sunxi.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 23baad9d934a..7119c02c9fa8 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -1290,17 +1290,13 @@ static void __init sunxi_clock_protect(void)
>
> /* memory bus clock - sun5i+ */
> clk = clk_get(NULL, "mbus");
> - if (!IS_ERR(clk)) {
> + if (!IS_ERR(clk))
> clk_prepare_enable(clk);
> - clk_put(clk);
> - }
>
> /* DDR clock - sun4i+ */
> clk = clk_get(NULL, "pll5_ddr");
> - if (!IS_ERR(clk)) {
> + if (!IS_ERR(clk))
> clk_prepare_enable(clk);
> - clk_put(clk);
> - }
> }
>
> static void __init sunxi_init_clocks(void)
> --
> 1.9.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 01/12] drm/nouveau: fix missing newline
On Mon, Mar 24, 2014 at 05:42:23PM +0900, Alexandre Courbot wrote: > Add a missing newline at the end of a DRM_INFO message. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Thierry Reding pgpH9jljXlYFi.pgp Description: PGP signature
Re: fs: gpf in simple_setattr
On Mon 24-03-14 10:42:25, Sasha Levin wrote: > On 03/10/2014 10:13 AM, Sasha Levin wrote: > >On 03/10/2014 06:43 AM, Jan Kara wrote: > >> By garbage, do you mean that it is a poison, completely random data or > >> does > >>inode->i_sb look like a valid pointer but just superblock isn't where it > >>points to? > > > >It's poison. > > > Any way I could get anything useful any other way? > >> Hum, can you dump the whole contents of 'dentry' at that place? Maybe it > >>will tell us something. > > > >I'll give it a go, will update when it happens again. > > Okay, I've added this: > > diff --git a/fs/libfs.c b/fs/libfs.c > index a184424..2492dc4 100644 > --- a/fs/libfs.c > +++ b/fs/libfs.c > @@ -377,6 +377,7 @@ int simple_setattr(struct dentry *dentry, struct iattr > *iattr) > if (iattr->ia_valid & ATTR_SIZE) > truncate_setsize(inode, iattr->ia_size); > setattr_copy(inode, iattr); > + printk(KERN_ERR "** %u %p %s %p %s %p %p %p\n", dentry->d_flags, > dentry->d_pare > mark_inode_dirty(inode); > return 0; > } > > And got the following: > > [ 339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0 > [eventpoll] 84666040 88056c73e7b0 (null) OK, great. So finally we have something useful. We know we have problems with [eventpoll] dentry. That is actually a special filesystem not mounted anywhere - likely you get to that dentry through /proc//fd/. Now eventpoll is interesting because it uses single anon inode for all eventpoll instances. And that inode should stay in place as long as eventpoll filesystem exists. So it's not clear how come that inode is freed. The basic check of handling of inode use count didn't find anything suspicious. But I can check in more detail and if I fail, we now have a pretty narrow area where to look... Honza > [ 339.956028] general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 339.958199] Dumping ftrace buffer: > [ 339.959158](ftrace buffer empty) > [ 339.960075] Modules linked in: > [ 339.960712] CPU: 2 PID: 9702 Comm: trinity-c2 Tainted: GW > 3.14.0-rc7-next-20140321-sasha-00018-g0516fe6-dirty #266 > [ 339.962657] task: 88012b8b ti: 88012b88a000 task.ti: > 88012b88a000 > [ 339.964089] RIP: 0010:[] [] > __mark_inode_dirty+0x10c/0x4a0 > [ 339.965274] RSP: 0018:88012b88bdb8 EFLAGS: 00010206 > [ 339.965274] RAX: 6b6b6b6b6b6b6b6b RBX: 8806ec051fe0 RCX: > 0006 > [ 339.965274] RDX: 8a90 RSI: 0007 RDI: > 8806ec051fe0 > [ 339.965274] RBP: 88012b88bdd8 R08: R09: > > [ 339.965274] R10: 0001 R11: 3330636135303838 R12: > 0007 > [ 339.965274] R13: 8806ec051fe0 R14: 8806ec6bb3d8 R15: > 8806ec051fe0 > [ 339.965274] FS: 7f1993d82700() GS:8800bec0() > knlGS: > [ 339.965274] CS: 0010 DS: ES: CR0: 8005003b > [ 339.974036] CR2: CR3: 000123b16000 CR4: > 06a0 > [ 339.974036] DR0: 00698000 DR1: DR2: > > [ 339.974036] DR3: DR6: 0ff0 DR7: > 0600 > [ 339.974036] Stack: > [ 339.974036] 8805ac03ba38 8806ec051fe0 > 88012b88bec8 > [ 339.974036] 88012b88be28 81336f7b 84666040 > 88056c73e7b0 > [ 339.974036] 8806ec0520c8 0041 > 88012b88bec8 > [ 339.974036] Call Trace: > [ 339.974036] [] simple_setattr+0xab/0xd0 > [ 339.974036] [] notify_change+0x258/0x390 > [ 339.974036] [] ? chmod_common+0x72/0x150 > [ 339.974036] [] chmod_common+0xb4/0x150 > [ 339.974036] [] ? __fget_light+0xe4/0x130 > [ 339.974036] [] SyS_fchmod+0x62/0xa0 > [ 339.974036] [] tracesys+0xe1/0xe6 > [ 339.974036] Code: 8b 45 00 0f 1f 40 00 49 8b 7d 08 44 89 e2 49 83 c5 10 48 > 89 de ff d0 49 8b 45 00 48 85 c0 75 e7 eb c5 0f 1f 44 00 00 49 8b 46 30 <48> > 8b 40 10 48 85 c0 74 08 44 89 e6 48 89 df ff d0 66 66 66 66 > [ 339.974036] RIP [] __mark_inode_dirty+0x10c/0x4a0 > [ 339.974036] RSP > > > Thanks, > Sasha -- Jan Kara SUSE Labs, CR -- 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: 3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)
On Mon, Mar 24, 2014 at 9:40 PM, Mikulas Patocka wrote: >> > > -> All hell breaks loose if Xorg dies and takes all it's mappings with it >> > > (in master_destroy, since the Xorg /dev fd is the master) and leaves the >> > > driver hanging in the air if there's an interrupt still pending (or >> > > anything else fwiw). >> > >> > For me that crash happened when xorg exited with a fatal error too. >> >> Is this fatal error itself a regression or have you seen that on older >> kernels, too? > > In my case that Xorg error was not kernel-related at all. It happened > because of unknown symbol because I used mga_dri.so from Debian 6 in > Debian 7 (mga_dri.so isn't shipped in Debian 7 anymore). I can still play > quake with that old mga_dri.so, although in some other scenario it causes > failure because of unknown symbol. I should probably recompile mga_dri on > my own. > >> Like I've said the entire teardown sequence for legacy drm drivers is >> terminally busted, so the only hope we have is to reapply this missing >> duct-tape which made your X crash. But if that itself isn't a regression >> there's no way to fix the current drm/mga driver without a complete >> rewrite as a new-style kernel modesetting driver. >> -Daniel > > If someone understands the locking issues I pointed out above, it could be > easy to fix. The locking issue isn't your problem, the real issue is that putting a irq_uninstall into core code will break all the new (properly working) drivers. And you can't really fix this in mga itself since the lifetime rules of the register mappings are totally broken. It's a fundamental misdesign of the legacy drm driver architecture and the _only_ way to fix this bug for real is to rewrite this all. Which was done for all the still used drivers like i915, radeon, nouveau, ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: line6: Fix missing blanks after declarations
On Mon, 2014-03-24 at 21:51 +0100, Fabian Mewes wrote: > This patch is part of eudyptula challenge task 10 > > Signed-off-by: Fabian Mewes Hi Fabian. The patch seems fine, but please do not use something like the above as a commit message. It would be better to describe _why_ the change should be done. Something like: -- Subject: [PATCH] staging: line6: Add blank lines after declarations Use the more common kernel coding style. Signed-off-by: your name -- 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: Disabling gcc inline operation
On Mon, Mar 24, 2014 at 2:33 AM, Arend van Spriel wrote: > On 23/03/14 23:31, anish singh wrote: >> >> Many a time i have got a crash and it is difficult >> to find out the exact function which crashed >> because the crash stack doesn't show the "real" >> function because gcc inlines many functions when >> ever it desires or when it optimizes for speed. >> >> So i don't want gcc to inline any function instead >> just call the function so that i can see the crash >> stack of each function called. I just want to do >> this for debugging. Please let me know how can >> i do that? >> >> What switch command to pass to gcc in the make >> of linux kernel? > > > You tried to look at gcc.gnu.org, right? Your best options are -O0 and/or > -Og for debugging purposes. It worked with -fno-inline > > Regards, > Arend > > >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ARM: mm: Fix for highmem on machines with more than 14 cores
On Mon, 24 Mar 2014, Anders Berg wrote: > The fixmap area was hard coded to 224 pages which was only enough for 14 > CPU:s. > Now the area adapts to the configured number of CPU:s (NR_CPUS). We still have > a hard limit of 30 CPU:s since we only have a single pte-chunk (512 pte:s). > > Signed-off-by: Anders Berg > Signed-off-by: Fredrik Markström This is under discussion already. Please have a look at this thread: http://news.gmane.org/group/gmane.linux.kernel/thread=1672068/ Nicolas
Futex Question (64 bits?)
I would like to know if it would be possible to use a 64 bit futex call? If not, I would like to request it be added. (It is acknowledged in the manpages that it must be added eventually anyway.) I am programming a C++11+ library. One of the constructed features is a "locking pointer". Unfortunately, pointers are usually 64 bits, while the futex call supports only 32 bits. I could not discover any documented way to invoke a 64 bit futex call. It's unfortunate in that the futex call must have a timeout set because of the possible deadlock condition where only the half of the pointer not futexed is modified between the time the system call is entered and executed. This creates a situation that prevents the locking_ptr from being realtime safe unless the timeout is set at a very low value. Furthermore, this causes excess CPU usage due to spurious wakeups. Thank you, Ryan Nicholl -- 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] ARM: mm: Fix for highmem on machines with more than 14 cores
Hi, While working of platform support for the LSI AXM5516 SoC (a 16 x A15 device) we ran into this limitation in fixmap.h where there is not enough room for the per-cpu pages if NR_CPUS is set to 16. The following patch avoids the overlap by lowering the base address according to the values of NR_CPUS and KM_TYPE_NR. Is this the way to handle this? Thanks, Anders Anders Berg (1): ARM: mm: Fix for highmem on machines with more than 14 cores arch/arm/include/asm/fixmap.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC] ARM: mm: Fix for highmem on machines with more than 14 cores
The fixmap area was hard coded to 224 pages which was only enough for 14 CPU:s. Now the area adapts to the configured number of CPU:s (NR_CPUS). We still have a hard limit of 30 CPU:s since we only have a single pte-chunk (512 pte:s). Signed-off-by: Anders Berg Signed-off-by: Fredrik Markström --- arch/arm/include/asm/fixmap.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h index bbae919..40f1f05 100644 --- a/arch/arm/include/asm/fixmap.h +++ b/arch/arm/include/asm/fixmap.h @@ -7,15 +7,15 @@ * On ARM we already have well known fixed virtual addresses imposed by * the architecture such as the vector page which is located at 0x, * therefore a second level page table is already allocated covering - * 0xfff0 upwards. + * 0xffe0 upwards. * * The cache flushing code in proc-xscale.S uses the virtual area between * 0xfffe and 0xfffe. */ -#define FIXADDR_START 0xfff0UL +#define FIXADDR_SIZE ((KM_TYPE_NR * NR_CPUS) << PAGE_SHIFT) #define FIXADDR_TOP0xfffeUL -#define FIXADDR_SIZE (FIXADDR_TOP - FIXADDR_START) +#define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE) #define FIX_KMAP_BEGIN 0 #define FIX_KMAP_END (FIXADDR_SIZE >> PAGE_SHIFT) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)
On Mon, 24 Mar 2014, Daniel Vetter wrote: > On Mon, Mar 24, 2014 at 01:17:12PM -0400, Mikulas Patocka wrote: > > > > > Hmm, given that Mikulas in > > > > > https://lkml.org/lkml/2014/2/26/537 > > > > > offered a diff of linux-3.13.5 files, it truly seems (shock! ack! > > > > > noo!) > > > > > that that indeed may have been a regression at <= 3.13 proper even > > > > > (which may pose interesting questions about the level of testing > > > > > coverage > > > > > we still enjoy [not!?] in this hardware area). > > > > That patch drops a mutex, so it is not correct. There is mutex resursion - > > we need to uninstall the irq in drm_master_destroy, because here we are > > committed to destroy the device. But the routine that uninstalls the irq > > takes struct_mutex, which is already held in drm_master_destroy. > > > > I suppose that the person who maintains drm reworks the patch so that it's > > correct: > > > > - could we use a different mutex to protect the irq in drm_irq.c? Or > > possibly no mutex at all and use cmpxchg to manipulate the variable > > dev->irq_enabled? - this seems like the best solution. But I am not sure > > if the code in drm_irq.c somehow depends on the facts that other parts of > > the drm subsystem take struct_mutex. > > > > - could we pass a new argument to drm_irq_uninstall that tells it not to > > take the mutex? drm_master_destroy would set this argument to 1. > > drm_master_destroy is mostly called with struct_mutex held, but there may > > be places in vmwgfx_drv.c where drm_master_put (which calls > > drm_master_destroy) may be called without struct_mutex held. > > > > Is it true that drm_master_destroy can be called without struct_mutex > > held? I don't know. > > > > > > I think drm maintainer should sort out the above issues and modify the > > patch accordingly. > > > > > -> All hell breaks loose if Xorg dies and takes all it's mappings with it > > > (in master_destroy, since the Xorg /dev fd is the master) and leaves the > > > driver hanging in the air if there's an interrupt still pending (or > > > anything else fwiw). > > > > For me that crash happened when xorg exited with a fatal error too. > > Is this fatal error itself a regression or have you seen that on older > kernels, too? In my case that Xorg error was not kernel-related at all. It happened because of unknown symbol because I used mga_dri.so from Debian 6 in Debian 7 (mga_dri.so isn't shipped in Debian 7 anymore). I can still play quake with that old mga_dri.so, although in some other scenario it causes failure because of unknown symbol. I should probably recompile mga_dri on my own. > Like I've said the entire teardown sequence for legacy drm drivers is > terminally busted, so the only hope we have is to reapply this missing > duct-tape which made your X crash. But if that itself isn't a regression > there's no way to fix the current drm/mga driver without a complete > rewrite as a new-style kernel modesetting driver. > -Daniel If someone understands the locking issues I pointed out above, it could be easy to fix. Mikulas -- 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] staging: line6: Fix missing blanks after declarations
This patch is part of eudyptula challenge task 10
Signed-off-by: Fabian Mewes
---
applies to next-20140324
drivers/staging/line6/driver.c | 1 +
drivers/staging/line6/playback.c | 5 +
drivers/staging/line6/toneport.c | 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index 77f1b42..ef511c7 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -124,6 +124,7 @@ static int line6_send_raw_message_async_part(struct message
*msg,
static int line6_start_listen(struct usb_line6 *line6)
{
int err;
+
usb_fill_int_urb(line6->urb_listen, line6->usbdev,
usb_rcvintpipe(line6->usbdev, line6->ep_control_read),
line6->buffer_listen, LINE6_BUFSIZE_LISTEN,
diff --git a/drivers/staging/line6/playback.c b/drivers/staging/line6/playback.c
index 41869ca..0f72db5 100644
--- a/drivers/staging/line6/playback.c
+++ b/drivers/staging/line6/playback.c
@@ -34,6 +34,7 @@ static void change_volume(struct urb *urb_out, int volume[],
if (bytes_per_frame == 4) {
short *p, *buf_end;
+
p = (short *)urb_out->transfer_buffer;
buf_end = p + urb_out->transfer_buffer_length / sizeof(*p);
@@ -48,6 +49,7 @@ static void change_volume(struct urb *urb_out, int volume[],
for (; p < buf_end; p += 3) {
int val;
+
val = p[0] + (p[1] << 8) + ((signed char)p[2] << 16);
val = (val * volume[chn & 1]) >> 8;
p[0] = val;
@@ -116,6 +118,7 @@ static void add_monitor_signal(struct urb *urb_out,
unsigned char *signal,
if (bytes_per_frame == 4) {
short *pi, *po, *buf_end;
+
pi = (short *)signal;
po = (short *)urb_out->transfer_buffer;
buf_end = po + urb_out->transfer_buffer_length / sizeof(*po);
@@ -171,6 +174,7 @@ static int submit_audio_out_urb(struct snd_line6_pcm
*line6pcm)
if (fsize == 0) {
int n;
+
line6pcm->count_out += frame_increment;
n = line6pcm->count_out / frame_factor;
line6pcm->count_out -= n * frame_factor;
@@ -207,6 +211,7 @@ static int submit_audio_out_urb(struct snd_line6_pcm
*line6pcm)
copy the data to the temp buffer.
*/
int len;
+
len = runtime->buffer_size - line6pcm->pos_out;
if (len > 0) {
diff --git a/drivers/staging/line6/toneport.c b/drivers/staging/line6/toneport.c
index af2e7e5..dcab647 100644
--- a/drivers/staging/line6/toneport.c
+++ b/drivers/staging/line6/toneport.c
@@ -213,6 +213,7 @@ static int snd_toneport_source_info(struct snd_kcontrol
*kcontrol,
struct snd_ctl_elem_info *uinfo)
{
const int size = ARRAY_SIZE(toneport_source_info);
+
uinfo->type = SNDRV_CTL_ELEM_TYPE_ENUMERATED;
uinfo->count = 1;
uinfo->value.enumerated.items = size;
--
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][v5] netlink: have netlink per-protocol bind function return an error code.
Have the netlink per-protocol optional bind function return an int error code
rather than void to signal a failure.
This will enable netlink protocols to perform extra checks including
capabilities and permissions verifications when updating memberships in
multicast groups.
In netlink_bind() and netlink_setsockopt() the call to the per-protocol bind
function was moved above the multicast group update to prevent any access to
the multicast socket groups before checking with the per-protocol bind
function. This will enable the per-protocol bind function to be used to check
permissions which could be denied before making them available, and to avoid
the messy job of undoing the addition should the per-protocol bind function
fail.
The netfilter subsystem seems to be the only one currently using the
per-protocol bind function.
Signed-off-by: Richard Guy Briggs
---
In particular, the audit subsystem (NETLINK_AUDIT protocol) could benefit by
being able to check specific capabilities for each multicast group before
granting membership to the requesting socket. Currently, all NETLINK_AUDIT
sockets must have the capability CAP_NET_ADMIN. No other capabilities are
required to join a multicast group. This capability is too broad allowing
access to this socket by many applications that must not have access to this
information. It is proposed to add capability CAP_AUDIT_READ to allow this
access while dropping the exessively broad capability CAP_NET_ADMIN.
There has also been some interest expressed by IETF ForCES folk.
v5: *really* fixed a logic error (missing braces) and a C99 error.
v3: added netlink_unbind() option and unwound netlink_insert().
---
include/linux/netlink.h |3 ++-
net/netfilter/nfnetlink.c |3 ++-
net/netlink/af_netlink.c | 39 ++-
net/netlink/af_netlink.h |6 --
4 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index 7a6c396..0ba2edd 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -45,7 +45,8 @@ struct netlink_kernel_cfg {
unsigned intflags;
void(*input)(struct sk_buff *skb);
struct mutex*cb_mutex;
- void(*bind)(int group);
+ int (*bind)(int group);
+ void(*unbind)(int group);
bool(*compare)(struct net *net, struct sock *sk);
};
diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
index 1da5ef1..14c8ac8 100644
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@ -392,7 +392,7 @@ static void nfnetlink_rcv(struct sk_buff *skb)
}
#ifdef CONFIG_MODULES
-static void nfnetlink_bind(int group)
+static int nfnetlink_bind(int group)
{
const struct nfnetlink_subsystem *ss;
int type = nfnl_group2type[group];
@@ -402,6 +402,7 @@ static void nfnetlink_bind(int group)
rcu_read_unlock();
if (!ss)
request_module("nfnetlink-subsys-%d", type);
+ return 0;
}
#endif
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index bca50b9..301dfe9 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1198,7 +1198,8 @@ static int netlink_create(struct net *net, struct socket
*sock, int protocol,
struct module *module = NULL;
struct mutex *cb_mutex;
struct netlink_sock *nlk;
- void (*bind)(int group);
+ int (*bind)(int group);
+ void (*unbind)(int group);
int err = 0;
sock->state = SS_UNCONNECTED;
@@ -1224,6 +1225,7 @@ static int netlink_create(struct net *net, struct socket
*sock, int protocol,
err = -EPROTONOSUPPORT;
cb_mutex = nl_table[protocol].cb_mutex;
bind = nl_table[protocol].bind;
+ unbind = nl_table[protocol].unbind;
netlink_unlock_table();
if (err < 0)
@@ -1240,6 +1242,7 @@ static int netlink_create(struct net *net, struct socket
*sock, int protocol,
nlk = nlk_sk(sock->sk);
nlk->module = module;
nlk->netlink_bind = bind;
+ nlk->netlink_unbind = unbind;
out:
return err;
@@ -1293,6 +1296,7 @@ static int netlink_release(struct socket *sock)
kfree_rcu(old, rcu);
nl_table[sk->sk_protocol].module = NULL;
nl_table[sk->sk_protocol].bind = NULL;
+ nl_table[sk->sk_protocol].unbind = NULL;
nl_table[sk->sk_protocol].flags = 0;
nl_table[sk->sk_protocol].registered = 0;
}
@@ -1441,6 +1445,22 @@ static int netlink_bind(struct socket *sock, struct
sockaddr *addr,
if (!nladdr->nl_groups && (nlk->groups == NULL || !(u32)nlk->groups[0]))
return 0;
+ if (nlk->netlink_bind && nladdr->nl_groups) {
+ int i;
+
+ for (i = 0; i < nlk->ngroups; i++)
+ if
[PATCH] drivers:staging:lustre Fixed sparse warning: plain integer as NULL pointer
Fixes these sparse warnings:
drivers/staging/lustre/lustre/lmv/lproc_lmv.c:202:51: warning: Using plain
integer as NULL pointer
drivers/staging/lustre/lustre/lmv/lproc_lmv.c:203:51: warning: Using plain
integer as NULL pointer
drivers/staging/lustre/lustre/lmv/lproc_lmv.c:204:51: warning: Using plain
integer as NULL pointer
drivers/staging/lustre/lustre/lmv/lproc_lmv.c:205:51: warning: Using plain
integer as NULL pointer
drivers/staging/lustre/lustre/lmv/lproc_lmv.c:206:51: warning: Using plain
integer as NULL pointer
drivers/staging/lustre/lustre/lmv/lproc_lmv.c:207:11: warning: Using plain
integer as NULL pointer
drivers/staging/lustre/lustre/lmv/lproc_lmv.c:213:47: warning: Using plain
integer as NULL pointer
drivers/staging/lustre/lustre/lmv/lproc_lmv.c:214:11: warning: Using plain
integer as NULL pointer
Signed-off-by: John de la Garza
---
drivers/staging/lustre/lustre/lmv/lproc_lmv.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
b/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
index b355d01..5d75e8c 100644
--- a/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
+++ b/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
@@ -199,19 +199,19 @@ static int lmv_target_seq_open(struct inode *inode,
struct file *file)
LPROC_SEQ_FOPS_RO_TYPE(lmv, uuid);
struct lprocfs_vars lprocfs_lmv_obd_vars[] = {
- { "numobd", _numobd_fops, 0, 0 },
- { "placement",_placement_fops,0, 0 },
- { "activeobd",_activeobd_fops,0, 0 },
- { "uuid", _uuid_fops, 0, 0 },
- { "desc_uuid",_desc_uuid_fops,0, 0 },
- { 0 }
+ { "numobd", _numobd_fops, NULL, 0 },
+ { "placement",_placement_fops,NULL, 0 },
+ { "activeobd",_activeobd_fops,NULL, 0 },
+ { "uuid", _uuid_fops, NULL, 0 },
+ { "desc_uuid",_desc_uuid_fops,NULL, 0 },
+ { NULL }
};
LPROC_SEQ_FOPS_RO_TYPE(lmv, numrefs);
static struct lprocfs_vars lprocfs_lmv_module_vars[] = {
- { "num_refs", _numrefs_fops, 0, 0 },
- { 0 }
+ { "num_refs", _numrefs_fops, NULL, 0 },
+ { NULL }
};
struct file_operations lmv_proc_target_fops = {
--
1.9.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/
[PATCH 4/6 V2] perf, sort: Add physid sorting based on mmap2 data
In order for the c2c tool to work correctly, it needs to properly
sort all the records on uniquely identifiable data addresses. These
unique addresses are converted from virtual addresses provided by the
hardware into a kernel address using an mmap2 record as the decoder.
Once a unique address is converted, we can sort on them based on
various rules. Then it becomes clear which address are overlapping
with each other across mmap regions or pid spaces.
This patch just creates the rules and inserts the records into a
sort entry for safe keeping until later patches process them.
The general sorting rule is:
o group cpumodes together
o if (nonzero major/minor number - ie mmap'd areas)
o sort on major, minor, inode, inode generation numbers
o else if cpumode is not kernel
o sort on pid
o sort on data addresses
I also hacked in the concept of 'color'. The purpose of that bit is to
provides hints later when processing these records that indicate a new unique
address has been encountered. Because later processing only checks the data
addresses, there can be a theoretical scenario that similar sequential data
addresses (when walking the rbtree) could be misinterpreted as overlapping
when in fact they are not.
Sample output: (perf report --stdio --physid-mode)
OverheadData AddressSource AddressCommand: Pid
Tid Major Minor Inode Inode Gen
.. .
. . . ... .
18.93% [k] 0xc900139c40b0 [k] igb_update_stats kworker/0:1: 257
257 0 0 0 0
7.63% [k] 0x88082e6cf0a8 [k] watchdog_timer_fnswapper:0
0 0 0 0 0
1.86% [k] 0x88042ef94700 [k] _raw_spin_lock swapper:0
0 0 0 0 0
1.77% [k] 0x8804278afa50 [k] __switch_to swapper:0
0 0 0 0 0
V4: add manpage entry in perf-report
V3: split out the sorting into unique entries. This makes it look
far less ugly
create a new 'physid mode' to group all the sorting rules together
(mimics the mem-mode)
Signed-off-by: Don Zickus
---
tools/perf/Documentation/perf-report.txt | 23 +++
tools/perf/builtin-report.c | 20 ++-
tools/perf/util/hist.c | 27 ++-
tools/perf/util/hist.h | 8 +
tools/perf/util/sort.c | 294 +++
tools/perf/util/sort.h | 13 ++
6 files changed, 381 insertions(+), 4 deletions(-)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 8eab8a4..01391b0 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -95,6 +95,23 @@ OPTIONS
And default sort keys are changed to comm, dso_from, symbol_from, dso_to
and symbol_to, see '--branch-stack'.
+ If --physid-mode option is used, following sort keys are also
+ available:
+ daddr, iaddr, pid, tid, major, minor, inode, inode_gen.
+
+ - daddr: data address (sorted based on major, minor, inode and inode
+ generation numbers if shared, otherwise pid)
+ - iaddr: instruction address
+ - pid: command and pid of the task
+ - tid: tid of the task
+ - major: major number of mapped location (0 if not mapped)
+ - minor: minor number of mapped location (0 if not mapped)
+ - inode: inode number of mapped location (0 if not mapped)
+ - inode_gen: inode generation number of mapped location (0 if not
mapped)
+
+ And default sort keys are changed to daddr, iaddr, pid, tid, major,
+ minor, inode and inode_gen, see '--physid-mode'.
+
-p::
--parent=::
A regex filter to identify parent. The parent is a caller of this
@@ -223,6 +240,12 @@ OPTIONS
branch stacks and it will automatically switch to the branch view mode,
unless --no-branch-stack is used.
+--physid-mode::
+ Use the data addresses sampled using perf record -d and combine them
+ with the mmap'd area region where they are located. This helps identify
+ which data addresses collide with similar addresses in another process
+ space. See --sort for output choices.
+
--objdump=::
Path to objdump binary.
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index c87412b..093f5ad 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -49,6 +49,7 @@ struct report {
boolshow_threads;
boolinverted_callchain;
boolmem_mode;
+ boolphysid_mode;
boolheader;
boolheader_only;
int max_stack;
@@ -241,7 +242,7 @@ static int
Re: [PATCH 01/15 V3] perf: Fix stddev calculation
On Mon, Mar 24, 2014 at 04:54:38PM -0400, Don Zickus wrote: > The stddev calculation written matched standard error. As a result when > using this result to find the relative stddev between runs, it was not > accurate. > This isn't the patch I that had my updates... Sorry for the noise. Cheers, Don -- 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 01/15 V3] perf: Fix stddev calculation
The stddev calculation written matched standard error. As a result when
using this result to find the relative stddev between runs, it was not
accurate.
Update the formula to match traditional stddev. Then rename the old
stddev calculation to stderr_stats in case someone wants to use it.
Signed-off-by: Don Zickus
---
tools/perf/util/stat.c | 13 +
tools/perf/util/stat.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/tools/perf/util/stat.c b/tools/perf/util/stat.c
index 6506b3d..0cb4dbc 100644
--- a/tools/perf/util/stat.c
+++ b/tools/perf/util/stat.c
@@ -33,6 +33,7 @@ double avg_stats(struct stats *stats)
* http://en.wikipedia.org/wiki/Stddev
*
* The std dev of the mean is related to the std dev by:
+ * (also known as standard error)
*
* s
* s_mean = ---
@@ -41,6 +42,18 @@ double avg_stats(struct stats *stats)
*/
double stddev_stats(struct stats *stats)
{
+ double variance;
+
+ if (stats->n < 2)
+ return 0.0;
+
+ variance = stats->M2 / (stats->n - 1);
+
+ return sqrt(variance);
+}
+
+double stderr_stats(struct stats *stats)
+{
double variance, variance_mean;
if (stats->n < 2)
diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
index ae8ccd7..6f61615 100644
--- a/tools/perf/util/stat.h
+++ b/tools/perf/util/stat.h
@@ -12,6 +12,7 @@ struct stats
void update_stats(struct stats *stats, u64 val);
double avg_stats(struct stats *stats);
double stddev_stats(struct stats *stats);
+double stderr_stats(struct stats *stats);
double rel_stddev_stats(double stddev, double avg);
static inline void init_stats(struct stats *stats)
--
1.7.11.7
--
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 trivial 2/3] workqueue: Spelling s/instensive/intensive/
On Mon, Mar 24, 2014 at 09:37:02PM +0100, Geert Uytterhoeven wrote: > From: Geert Uytterhoeven > > Signed-off-by: Geert Uytterhoeven > Cc: Tejun Heo Applied to wq/for-3.15. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf/tool: Fix usage of trace events with '-' in trace system name.
From: Alexander Yarygin
Trace events potentially can have a '-' in their trace system name,
e.g. kvm on s390 defines kvm-s390:* tracepoints.
tools/perf could not parse them, because there was no rule for this:
$ sudo ./perf top -e "kvm-s390:*"
invalid or unsupported event: 'kvm-s390:*'
This patch adds an extra rule to event_legacy_tracepoint which handles
those cases. Without the patch, perf will not accept such tracepoints in
the -e option.
Signed-off-by: Alexander Yarygin
Signed-off-by: Christian Borntraeger
---
tools/perf/util/parse-events.y | 12
1 file changed, 12 insertions(+)
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 4eb67ec..dbbb01c 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -299,6 +299,18 @@ PE_PREFIX_MEM PE_VALUE sep_dc
}
event_legacy_tracepoint:
+PE_NAME '-' PE_NAME ':' PE_NAME
+{
+ struct parse_events_evlist *data = _data;
+ struct list_head *list;
+ char sys_name[strlen($1) + strlen($3) + 2];
+ sprintf(_name, "%s-%s", $1, $3);
+
+ ALLOC_LIST(list);
+ ABORT_ON(parse_events_add_tracepoint(list, >idx, _name, $5));
+ $$ = list;
+}
+|
PE_NAME ':' PE_NAME
{
struct parse_events_evlist *data = _data;
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: New NAND driver
On Monday, March 24, 2014 at 02:24:46 PM, Lee Jones wrote: > Hi Brian, > > Firstly I'd like to thank you for supporting the inclusion of ST's SPI > NOR (FSM) driver. As promised I will convert it over to the new > framework once it has been applied by your good self. > > In the meantime however, I have a NAND driver which I need to > submit. I wanted to give you a heads-up prior to sending it in case > you had any special requests. FYI: Shoving it where the sun don't > shine, is not a valid request by the way :). It's 2700 lines and I've > split it over 47 patches for reviewing purposes. One nand driver in 47 patches ? Whoa ;-) Best regards, Marek Vasut -- 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 trivial 1/3] megaraid_sas: Spelling s/intance/instance/
From: Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven
Cc: Neela Syam Kolli
Cc: linux-s...@vger.kernel.org
---
drivers/scsi/megaraid/megaraid_sas_base.c |2 +-
drivers/scsi/megaraid/megaraid_sas_fusion.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 3b7ad10497fe..10082678077c 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -3865,7 +3865,7 @@ fail_ready_state:
/**
* megasas_release_mfi - Reverses the FW initialization
- * @intance: Adapter soft state
+ * @instance: Adapter soft state
*/
static void megasas_release_mfi(struct megasas_instance *instance)
{
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index f6555921fd7a..f7d68f65f974 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2164,7 +2164,7 @@ megasas_issue_dcmd_fusion(struct megasas_instance
*instance,
/**
* megasas_release_fusion -Reverses the FW initialization
- * @intance: Adapter soft state
+ * @instance: Adapter soft state
*/
void
megasas_release_fusion(struct megasas_instance *instance)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
