Re: [next-20141231] sched: WARNING: CPU: 1 PID: 2539 at kernel/sched/core.c:7303 __might_sleep+0xbd/0xd0()
On Sun, Jan 4, 2015 at 1:59 AM, Ming Lei wrote: > Hi Sedat, > > On Sun, Jan 4, 2015 at 7:42 AM, Sedat Dilek wrote: >> On Thu, Jan 1, 2015 at 11:28 AM, Sedat Dilek wrote: >>> Hi, >>> >>> with next-20141231 I am seeing this call-trace: >>> >>> [ 88.028632] [ cut here ] >>> [ 88.028643] WARNING: CPU: 1 PID: 2539 at kernel/sched/core.c:7303 >>> __might_sleep+0xbd/0xd0() >>> [ 88.028646] do not call blocking ops when !TASK_RUNNING; state=1 >>> set at [] prepare_to_wait_event+0x5d/0x110 >>> [ 88.028648] Modules linked in: ppp_deflate bsd_comp ppp_async >>> crc_ccitt arc4 iwldvm uvcvideo mac80211 snd_hda_codec_hdmi >>> snd_hda_codec_realtek parport_pc videobuf2_vmalloc >>> snd_hda_codec_generic ppdev videobuf2_memops snd_hda_intel >>> videobuf2_core rfcomm bnep snd_hda_controller option snd_hda_codec >>> v4l2_common i915 joydev videodev usb_wwan snd_hwdep usbserial >>> cdc_ether snd_pcm usbnet btusb snd_seq_midi snd_seq_midi_event >>> bluetooth psmouse snd_rawmidi iwlwifi snd_seq i2c_algo_bit >>> drm_kms_helper snd_timer serio_raw snd_seq_device samsung_laptop drm >>> snd cfg80211 soundcore video lpc_ich intel_rst wmi mac_hid binfmt_misc >>> lp parport hid_generic usbhid hid r8169 mii usb_storage >>> [ 88.028694] CPU: 1 PID: 2539 Comm: fio Not tainted >>> 3.19.0-rc2-next20141231-1-iniza-small #1 >>> [ 88.028695] Hardware name: SAMSUNG ELECTRONICS CO., LTD. >>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 >>> [ 88.028697] 81a66d5f 880070f43c38 8175c50c >>> >>> [ 88.028700] 880070f43c88 880070f43c78 810753ba >>> 880070f43d28 >>> [ 88.028703] 81a67ef5 026d >>> 00dce810 >>> [ 88.028706] Call Trace: >>> [ 88.028712] [] dump_stack+0x4c/0x65 >>> [ 88.028716] [] warn_slowpath_common+0x8a/0xc0 >>> [ 88.028719] [] warn_slowpath_fmt+0x46/0x50 >>> [ 88.028722] [] ? mark_held_locks+0x6d/0xa0 >>> [ 88.028725] [] ? mutex_lock_nested+0x2b2/0x4e0 >>> [ 88.028727] [] ? prepare_to_wait_event+0x5d/0x110 >>> [ 88.028729] [] ? prepare_to_wait_event+0x5d/0x110 >>> [ 88.028731] [] __might_sleep+0xbd/0xd0 >>> [ 88.028734] [] mutex_lock_nested+0x2f/0x4e0 >>> [ 88.028736] [] ? prepare_to_wait_event+0x53/0x110 >>> [ 88.028739] [] aio_read_events+0x4f/0x2d0 >>> [ 88.028742] [] ? trace_hardirqs_on+0xd/0x10 >>> [ 88.028745] [] read_events+0x200/0x320 >>> [ 88.028747] [] ? wait_woken+0xc0/0xc0 >>> [ 88.028750] [] ? hrtimer_get_res+0x50/0x50 >>> [ 88.028753] [] ? lookup_ioctx+0xd0/0x140 >>> [ 88.028755] [] SyS_io_getevents+0x62/0x100 >>> [ 88.028759] [] ? trace_hardirqs_on_thunk+0x3a/0x3f >>> [ 88.028762] [] system_call_fastpath+0x16/0x1b >>> [ 88.028764] ---[ end trace dba4f4a06fcdd178 ]--- > > It is an known linux-aio issue, see the following link: > > http://marc.info/?t=14192504964=1=2 > This discussion resulted in a RFC patch of Chris Mason which is still discussed in [1]. - Sedat - [1] http://marc.info/?t=14192939611=1=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: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
2015-01-04 1:45 GMT+09:00 Nishanth Menon : > On 01/03/2015 10:16 AM, Tomasz Figa wrote: >> >> 2015-01-04 0:34 GMT+09:00 Nishanth Menon : >>> >>> On 15:40-20150103, Tomasz Figa wrote: >>>> >>>> Hi Nishanth, >>>> >>>> 2015-01-03 2:43 GMT+09:00 Nishanth Menon : >>>>> >>>>> AM437x generation of processors support programming the PL310 L2Cache >>>>> controller's address filter start and end registers using a secure >>>>> montior service. >>>> >>>> >>>> typo: s/montior/monitor/ >>>> >>>> [snip] >>> >>> >>> Uggh.. yes indeed. I will post a v3 updating the comments. If the >>> following is ok. >>>> >>>> >>>>> + base = omap4_get_l2cache_base(); >>>>> + filter_start = (reg == L310_ADDR_FILTER_START) ? val : >>>>> + readl_relaxed(base + >>>>> L310_ADDR_FILTER_START); >>>>> + filter_end = (reg == L310_ADDR_FILTER_END) ? val : >>>>> + readl_relaxed(base + >>>>> L310_ADDR_FILTER_END); >>>>> + omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, >>>>> filter_start, >>>>> + filter_end); >>>>> + return; >>>> >>>> >>>> I don't have any significant comments about this patch in particular, >>>> but just noticed that you need to do read-backs here (and the typo >>>> thanks to the spell checker of my mailing app). Maybe you should >>>> consider switching to the .configure() API I introduced in my series? >>>> This would let you get rid of the hardcoded static mapping. >>> >>> >>> Yeah, I have two choices there.. Either I provide the fundamental >>> write function for the generic l2c code to use OR I provide a >>> duplicate of resultant l2c_configure(aux write) + l2c310_configure. >>> >>> To allow for reuse of improvements or anything like errata >>> implementations in the future, OMAP L2C implementation has chosen to >>> provide the >>> low level code and allow the higherlevel configure/write/whatever of the >>> future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is >>> not too complicated enough to warrant a replication of l2c310_configure. >>> >>> So, I prefer the current implementation than providing a .configure >>> handler for outer_cache.configure from SoC level. >>> >>> Let me know if anyone has a strong objection to this. >> >> >> Well, what l2c310_configure() does after my series is just writing the >> registers. If they cannot be written normally (without some tricks >> such as reading back other registers) then IMHO a separate function >> should be provided. >> >> This is becomes possible after patch 3/8 (ARM: l2c: Add interface to >> ask hypervisor to configure L2C) and what is used on Exynos which also >> updates multiple registers in single SMC calls. You can find an >> example of use in patch 6/8 (ARM: EXYNOS: Add .write_sec outer cache >> callback for L2C-310). What's even more interesting is that approaches >> similar to the one currently used on OMAP had been NAKed, when >> proposed for Exynos and this is why we have the solution proposed by >> my patches. >> >> Note that .write_sec() callback is still used for L2X0_CTRL and >> L2X0_DEBUG_CTRL registers, because there might be a need to write them >> separately (e.g. to disable the controller and to perform debug >> operations/workarounds when the controller is already enabled). > > > > we dont have a machine descriptor for configure instead we overide the > logic(in you case after firmware load, in OMAP case, I need to figure out). > my point being unlike the exynos configure code, OMAP code will look exactly > like current pl310_configure-2 lines of code which really does not benefit > anything. > > > Thinking again, in fact, i'd rather drop this series than have to do a > duplicated configure code(and force a resultant maintenance for the future) > in OMAP code since none of OMAP4 or AM437x series need these patches. > Interest for this series was non-mandatory, but just to be complete from SoC > definition point of view. > > Let me know which way you guys want me to go. Right, dropping this series would definitely solve the the read-back issue. :) After all, if you don't need to override the latencies in the kernel (i.e. have sane firmware, unlike certain Exynos boards ;)), then I don't see a point of having this feature. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] staging: rtl8192e: Fix duplicated conditional branch
Signed-off-by: Alexander Kuleshov
---
drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
index 885315c..b8891c6 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
@@ -1661,8 +1661,8 @@ void dm_change_dynamic_initgain_thresh(struct net_device
*dev,
dm_digtable.rssi_low_thresh = dm_value;
} else if (dm_type == DIG_TYPE_THRESH_HIGHPWR_HIGH) {
dm_digtable.rssi_high_power_highthresh = dm_value;
- } else if (dm_type == DIG_TYPE_THRESH_HIGHPWR_HIGH) {
- dm_digtable.rssi_high_power_highthresh = dm_value;
+ } else if (dm_type == DIG_TYPE_THRESH_HIGHPWR_LOW) {
+ dm_digtable.rssi_high_power_lowthresh = dm_value;
} else if (dm_type == DIG_TYPE_ENABLE) {
dm_digtable.dig_state = DM_STA_DIG_MAX;
dm_digtable.dig_enable_flag = true;
--
2.2.1.202.g44ae4ee.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] arch: m68k: mac: misc.c: Remove some unused functions
On Thu, 1 Jan 2015, Rickard Strandqvist wrote:
> Removes some functions that are not used anywhere:
> mac_pram_write() mac_pram_read()
>
If you remove those functions, you'd then find that all of the called
functions become unused:
maciisi_read_pram
maciisi_write_pram
pmu_read_pram
pmu_write_pram
cuda_read_pram
cuda_write_pram
via_read_pram
via_write_pram
I'd rather not remove all of this code. Better to finish the
implementation.
If we provide access to the PRAM (i.e. NVRAM) from userspace then the
EMILE bootloader would be able to assign the boot device, for example.
Within the kernel, the CUDA PRAM functions could be used by valkyriefb to
determine the correct default video mode (see comment in that driver).
Would it be acceptable to utilize drivers/char/generic_nvram.c and
CONFIG_GENERIC_NVRAM? This is the PowerMac PRAM driver but looks generic
enough that it may not need any modification for 68k Macs.
--
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> arch/m68k/mac/misc.c | 46 --
> 1 file changed, 46 deletions(-)
>
> diff --git a/arch/m68k/mac/misc.c b/arch/m68k/mac/misc.c
> index 707b61a..6fe7eb6 100644
> --- a/arch/m68k/mac/misc.c
> +++ b/arch/m68k/mac/misc.c
> @@ -453,52 +453,6 @@ void pmu_shutdown(void)
> *---
> */
>
> -void mac_pram_read(int offset, __u8 *buffer, int len)
> -{
> - __u8 (*func)(int);
> - int i;
> -
> - switch(macintosh_config->adb_type) {
> - case MAC_ADB_IISI:
> - func = maciisi_read_pram; break;
> - case MAC_ADB_PB1:
> - case MAC_ADB_PB2:
> - func = pmu_read_pram; break;
> - case MAC_ADB_CUDA:
> - func = cuda_read_pram; break;
> - default:
> - func = via_read_pram;
> - }
> - if (!func)
> - return;
> - for (i = 0 ; i < len ; i++) {
> - buffer[i] = (*func)(offset++);
> - }
> -}
> -
> -void mac_pram_write(int offset, __u8 *buffer, int len)
> -{
> - void (*func)(int, __u8);
> - int i;
> -
> - switch(macintosh_config->adb_type) {
> - case MAC_ADB_IISI:
> - func = maciisi_write_pram; break;
> - case MAC_ADB_PB1:
> - case MAC_ADB_PB2:
> - func = pmu_write_pram; break;
> - case MAC_ADB_CUDA:
> - func = cuda_write_pram; break;
> - default:
> - func = via_write_pram;
> - }
> - if (!func)
> - return;
> - for (i = 0 ; i < len ; i++) {
> - (*func)(offset++, buffer[i]);
> - }
> -}
> -
> void mac_poweroff(void)
> {
> /*
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: gdm724x: fix coding style issues
OK, then this one is abandoned. I will send two patches instead.
/Ning
On 2015-01-04 02:27, Konrad Zapalowicz wrote:
> On 01/03, Ning Zhou wrote:
>> Signed-off-by: Ning Zhou
>
> You need to describe your changes, a vague subject is not enough. Also
> keep in mind that one patch shall address one category of stuff and
> seems that yours could be separated into two.
>
> thanks,
> konrad
>
>> ---
>> drivers/staging/gdm724x/gdm_lte.c | 3 ++-
>> drivers/staging/gdm724x/gdm_mux.c | 2 +-
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/gdm724x/gdm_lte.c
>> b/drivers/staging/gdm724x/gdm_lte.c
>> index 73eede1..7c4a77b 100644
>> --- a/drivers/staging/gdm724x/gdm_lte.c
>> +++ b/drivers/staging/gdm724x/gdm_lte.c
>> @@ -281,7 +281,8 @@ static int gdm_lte_emulate_ndp(struct sk_buff *skb_in,
>> u32 nic_type)
>> icmp6_out.icmp6_type = NDISC_NEIGHBOUR_ADVERTISEMENT;
>> icmp6_out.icmp6_code = 0;
>> icmp6_out.icmp6_cksum = 0;
>> -icmp6_out.icmp6_dataun.un_data32[0] = htonl(0x6000); /*
>> R=0, S=1, O=1 */
>> +/* R=0, S=1, O=1 */
>> +icmp6_out.icmp6_dataun.un_data32[0] = htonl(0x6000);
>>
>> ns = (struct neighbour_solicitation *)
>> (skb_in->data + mac_header_len +
>> diff --git a/drivers/staging/gdm724x/gdm_mux.c
>> b/drivers/staging/gdm724x/gdm_mux.c
>> index b5b063a..d1ab996 100644
>> --- a/drivers/staging/gdm724x/gdm_mux.c
>> +++ b/drivers/staging/gdm724x/gdm_mux.c
>> @@ -220,7 +220,7 @@ static int up_to_host(struct mux_rx *r)
>> static void do_rx(struct work_struct *work)
>> {
>> struct mux_dev *mux_dev =
>> -container_of(work, struct mux_dev , work_rx.work);
>> +container_of(work, struct mux_dev, work_rx.work);
>> struct mux_rx *r;
>> struct rx_cxt *rx = (struct rx_cxt *)_dev->rx;
>> unsigned long flags;
>> --
>> 1.9.1
>>
>> ___
>> 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/
[PATCH 2/2] staging: android: ion: Add pss info for each ion_client
In real ION buffer usage, many of the ion buffer are shared
by several clients(imported and exported), and current ion
debugfs only provides size of all buffers a client may use.
This patch will considers the sharing and adds a "pss" info
for each ion_client, which will help on profiling the ion
memory usage.
Actually we can do more aggressively in android world, in
which the "surfaceflinger" is a main proxy to help other
apps to do the ion buffer allocation, and we can consider
this and extract "surfaceflinger" related size out. And
this could be the next step.
Signed-off-by: Feng Tang
---
drivers/staging/android/ion/ion.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 3d378ef..0b8fd56 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1386,18 +1386,25 @@ static const struct file_operations ion_fops = {
};
static size_t ion_debug_heap_total(struct ion_client *client,
- unsigned int id)
+ unsigned int id, size_t *psize)
{
size_t size = 0;
struct rb_node *n;
+ *psize = 0;
+
mutex_lock(>lock);
for (n = rb_first(>handles); n; n = rb_next(n)) {
struct ion_handle *handle = rb_entry(n,
struct ion_handle,
node);
- if (handle->buffer->heap->id == id)
+ if (handle->buffer->heap->id == id) {
size += handle->buffer->size;
+ if (handle->buffer->handle_count)
+ *psize += handle->buffer->size /
+ handle->buffer->handle_count;
+ }
+
}
mutex_unlock(>lock);
return size;
@@ -1411,13 +1418,15 @@ static int ion_debug_heap_show(struct seq_file *s, void
*unused)
size_t total_size = 0;
size_t total_orphaned_size = 0;
- seq_printf(s, "%16.s %16.s %16.s\n", "client", "pid", "size");
+ seq_printf(s, "%16.s %16.s %16.s %16.s\n",
+ "client", "pid", "size", "psize");
seq_puts(s, "\n");
for (n = rb_first(>clients); n; n = rb_next(n)) {
struct ion_client *client = rb_entry(n, struct ion_client,
node);
- size_t size = ion_debug_heap_total(client, heap->id);
+ size_t psize;
+ size_t size = ion_debug_heap_total(client, heap->id, );
if (!size)
continue;
@@ -1425,11 +1434,11 @@ static int ion_debug_heap_show(struct seq_file *s, void
*unused)
char task_comm[TASK_COMM_LEN];
get_task_comm(task_comm, client->task);
- seq_printf(s, "%16.s %16u %16zu\n", task_comm,
- client->pid, size);
+ seq_printf(s, "%16.s %16u %16zu %16zu\n", task_comm,
+ client->pid, size, psize);
} else {
- seq_printf(s, "%16.s %16u %16zu\n", client->name,
- client->pid, size);
+ seq_printf(s, "%16.s %16u %16zu %16zu\n", client->name,
+ client->pid, size, psize);
}
}
seq_puts(s, "\n");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] staging: andriod: ion: Add ion_phys_get_by_id function
There is user case that user only knows the ion_handle idand
needs to get the physical addr and len. So add this wrapper to
meet this requirement.
Signed-off-by: Feng Tang
---
drivers/staging/android/ion/ion.c | 16
drivers/staging/android/ion/ion.h | 14 ++
2 files changed, 30 insertions(+)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 296d347..3d378ef 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -577,6 +577,22 @@ int ion_phys(struct ion_client *client, struct ion_handle
*handle,
}
EXPORT_SYMBOL(ion_phys);
+int ion_phys_get_by_id(struct ion_client *client, int id,
+ion_phys_addr_t *addr, size_t *len)
+{
+ struct ion_handle *handle;
+ int ret;
+
+ handle = ion_handle_get_by_id(client, id);
+ if (!handle)
+ return -EINVAL;
+
+ ret = ion_phys(client, handle, addr, len);
+ ion_handle_put(handle);
+ return ret;
+}
+EXPORT_SYMBOL(ion_phys_get_by_id);
+
static void *ion_buffer_kmap_get(struct ion_buffer *buffer)
{
void *vaddr;
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index 443db84..9ef0f18 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -147,6 +147,20 @@ int ion_phys(struct ion_client *client, struct ion_handle
*handle,
ion_phys_addr_t *addr, size_t *len);
/**
+ * ion_phys_get_by_id - returns the physical address and len of a handle
+ * @client:the client
+ * @id:id bound to ion_handle, which may be passed to user
space
+ * @addr: a pointer to put the address in
+ * @len: a pointer to put the length in
+ *
+ * This function will first get ion_handle from the id, and then
+ * use upper ion_phys() to get the physical and len.
+ */
+
+int ion_phys_get_by_id(struct ion_client *client, int id,
+ion_phys_addr_t *addr, size_t *len);
+
+/**
* ion_map_dma - return an sg_table describing a handle
* @client:the client
* @handle:the handle
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8192e: Fix duplicated conditional branch
On Sun, 2015-01-04 at 12:59 +0600, Alexander Kuleshov wrote:
> Signed-off-by: Alexander Kuleshov
[]
> diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
> b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
[]
> @@ -1661,7 +1661,7 @@ void dm_change_dynamic_initgain_thresh(struct
> net_device *dev,
> dm_digtable.rssi_low_thresh = dm_value;
> } else if (dm_type == DIG_TYPE_THRESH_HIGHPWR_HIGH) {
> dm_digtable.rssi_high_power_highthresh = dm_value;
> - } else if (dm_type == DIG_TYPE_THRESH_HIGHPWR_HIGH) {
> + } else if (dm_type == DIG_TYPE_THRESH_HIGHPWR_LOW) {
> dm_digtable.rssi_high_power_highthresh = dm_value;
> } else if (dm_type == DIG_TYPE_ENABLE) {
> dm_digtable.dig_state = DM_STA_DIG_MAX;
Presumably, this is a copy/paste error and should have
both lines changed to HIGHPWR_LOW/high_power_lowthresh
else if (dm_type == DIG_TYPE_THRESH_HIGHPWR_LOW)
dm_digtable.rssi_high_power_lowthresh = dm_value;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: rtl8192e: Fix duplicated conditional branch
Signed-off-by: Alexander Kuleshov
---
drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
index 885315c..9010d0f 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
@@ -1661,7 +1661,7 @@ void dm_change_dynamic_initgain_thresh(struct net_device
*dev,
dm_digtable.rssi_low_thresh = dm_value;
} else if (dm_type == DIG_TYPE_THRESH_HIGHPWR_HIGH) {
dm_digtable.rssi_high_power_highthresh = dm_value;
- } else if (dm_type == DIG_TYPE_THRESH_HIGHPWR_HIGH) {
+ } else if (dm_type == DIG_TYPE_THRESH_HIGHPWR_LOW) {
dm_digtable.rssi_high_power_highthresh = dm_value;
} else if (dm_type == DIG_TYPE_ENABLE) {
dm_digtable.dig_state = DM_STA_DIG_MAX;
--
2.2.1.202.g44ae4ee.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/
[PATCH RFC] usb: chipidea: add support for usb_phy in generic usb2
Signed-off-by: Baruch Siach --- drivers/usb/chipidea/ci_hdrc_usb2.c | 5 + 1 file changed, 5 insertions(+) I'm sending this as RFC as I'm not sure this is the right thing to do. There seems to be a move away from USB specific PHY drivers towards the generic PHY framework (drivers/phy). The trouble is that my PHY is similar to the mxs PHY (phy-mxs-usb.c), and like mxs I need the notify_connect/notify_disconnect callbacks. This functionality is not available is the generic PHY framework. Having support for both 'usb-phy' and 'phy' properties (as dwc3 seems to do) is particularly bad, since the distinction between the two is a Linux implementation detail that has nothing to do with hardware description. So my questions are: 1. Is there a plan to add notifications support to the generic PHY? 2. If not, what are my options? Thanks, baruch diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c b/drivers/usb/chipidea/ci_hdrc_usb2.c index 45844c951788..cc3aeb781a57 100644 --- a/drivers/usb/chipidea/ci_hdrc_usb2.c +++ b/drivers/usb/chipidea/ci_hdrc_usb2.c @@ -35,11 +35,16 @@ static int ci_hdrc_usb2_probe(struct platform_device *pdev) struct device *dev = >dev; struct ci_hdrc_usb2_priv *priv; struct ci_hdrc_platform_data *ci_pdata = dev_get_platdata(dev); + struct usb_phy *usb_phy; int ret; if (!ci_pdata) ci_pdata = _default_pdata; + usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0); + if (!IS_ERR(usb_phy)) + ci_pdata->usb_phy = usb_phy; + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] samples: hw_breakpoint: check the return value of kallsyms_lookup_name
data_breakpoint.ko can insert successful but cannot catch any change of
the data in my part because kallsyms_lookup_name rerurn 0 each time.
So add code to check the return value of kallsyms_lookup_name.
Signed-off-by: Hui Zhu
---
samples/hw_breakpoint/data_breakpoint.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/samples/hw_breakpoint/data_breakpoint.c
b/samples/hw_breakpoint/data_breakpoint.c
index ef7f322..4fbf93b 100644
--- a/samples/hw_breakpoint/data_breakpoint.c
+++ b/samples/hw_breakpoint/data_breakpoint.c
@@ -52,27 +52,30 @@ static void sample_hbp_handler(struct perf_event *bp,
static int __init hw_break_module_init(void)
{
- int ret;
+ int ret = 0;
struct perf_event_attr attr;
hw_breakpoint_init();
attr.bp_addr = kallsyms_lookup_name(ksym_name);
+ if (!attr.bp_addr) {
+ ret = -ENXIO;
+ printk(KERN_INFO "Get address for %s failed\n", ksym_name);
+ goto out;
+ }
+
attr.bp_len = HW_BREAKPOINT_LEN_4;
attr.bp_type = HW_BREAKPOINT_W | HW_BREAKPOINT_R;
sample_hbp = register_wide_hw_breakpoint(, sample_hbp_handler,
NULL);
if (IS_ERR((void __force *)sample_hbp)) {
ret = PTR_ERR((void __force *)sample_hbp);
- goto fail;
+ printk(KERN_INFO "Breakpoint registration failed\n");
+ goto out;
}
printk(KERN_INFO "HW Breakpoint for %s write installed\n", ksym_name);
- return 0;
-
-fail:
- printk(KERN_INFO "Breakpoint registration failed\n");
-
+out:
return ret;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] input: Add soft kill switch for input devices
This adds a sysfs attribute named 'mute' to all input devices.
It allows to disable them by software in a generic way.
It can be set to 0 or 1:
echo 1 > /sys/class/input/inputX/mute: will set all the input_events() call to
return immediately.
echo 0 > /sys/class/input/inputX/mute: will reset to default behavior.
mute is set to 0 by default when calling alloc_input_device().
Signed-off-by: Tristan Lelong
---
Hi,
I created this patch to answer a need on my machine: I want to be able to
disable momentarily the touchscreen
in order to wipe out a dust or clean the display without creating a mess on my
desktop and opened docs.
It seemed consistent to have that kill switch at a central point, and moreover,
it doesn't depend on any tool linked to a specifc X server, graphical toolkit,
desktop environment...
This patch uses the 0/1 values to enable or disable the mute, but I could
update it to use
enable/disable instead if it is preferred.
Also, the permissions are write for group or ownoer only.
I thought about setting it world writable in order to allow easy shortcut
creation, but it might also be a security flaw.
Let me know what you think about all this, at least it is really useful in my
case, linked to a keyboard shortcut.
Best regards
---
drivers/input/input.c | 30 +-
include/linux/input.h | 1 +
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index a1e609a..2f80fee 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -425,7 +425,7 @@ void input_event(struct input_dev *dev,
{
unsigned long flags;
- if (is_event_supported(type, dev->evbit, EV_MAX)) {
+ if (!dev->mute && is_event_supported(type, dev->evbit, EV_MAX)) {
spin_lock_irqsave(>event_lock, flags);
input_handle_event(dev, type, code, value);
@@ -1384,10 +1384,38 @@ static ssize_t input_dev_show_properties(struct device
*dev,
}
static DEVICE_ATTR(properties, S_IRUGO, input_dev_show_properties, NULL);
+static ssize_t input_dev_show_mute(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+ struct input_dev *input_dev = to_input_dev(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", input_dev->mute);
+}
+
+static ssize_t input_dev_store_mute(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int err;
+ long mute;
+ struct input_dev *input_dev = to_input_dev(dev);
+
+ err = kstrtol(buf, 0, );
+ if (err < 0)
+ return err;
+ input_dev->mute = mute;
+
+ return count;
+}
+static DEVICE_ATTR(mute, S_IRUGO | S_IWUSR | S_IWGRP, input_dev_show_mute,
+ input_dev_store_mute);
+
static struct attribute *input_dev_attrs[] = {
_attr_name.attr,
_attr_phys.attr,
_attr_uniq.attr,
+ _attr_mute.attr,
_attr_modalias.attr,
_attr_properties.attr,
NULL
diff --git a/include/linux/input.h b/include/linux/input.h
index 3b4c32f..e45672f 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -151,6 +151,7 @@ struct input_dev {
struct ff_device *ff;
+ unsigned int mute;
unsigned int repeat_key;
struct timer_list timer;
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] brcm80211: brcmsmac: dma: Remove some unused functions
On 01/03/2015 06:47 PM, Rickard Strandqvist wrote: Removes some functions that are not used anywhere: dma_txflush() dma_txsuspended() This was partially found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist --- drivers/net/wireless/brcm80211/brcmsmac/dma.c | 19 --- drivers/net/wireless/brcm80211/brcmsmac/dma.h |2 -- 2 files changed, 21 deletions(-) Just because file dma.c is involved, it does not need to be, nor should it be in the subject line. You could specify the driver names in the file tree after wireless. In this instance, one possible subject would be "brcm80211: brcmsmac: Remove some unused functions". On the other hand, if you look at "git log" to see past patches, the driver maintainers even leave off the brcm80211 part, thus to match them, the subject should be "brcmsmac: Remove some unused functions". As was suggested earlier, you need to look at the precedents. Keeping a uniform method of patch naming helps when looking for patches in the git log. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Re: [PATCH v3 05/20] selftests/ftrace: add install target to enable test install
(2015/01/03 0:45), Steven Rostedt wrote: > On Wed, 24 Dec 2014 09:27:41 -0700 > Shuah Khan wrote: > >> Add a new make target to enable installing test. This target >> installs test in the kselftest install location and add to the >> kselftest script to run the test. Install target can be run >> only from top level kernel source directory. >> >> Signed-off-by: Shuah Khan >> --- >> tools/testing/selftests/ftrace/Makefile | 11 ++- >> 1 file changed, 10 insertions(+), 1 deletion(-) >> >> diff --git a/tools/testing/selftests/ftrace/Makefile >> b/tools/testing/selftests/ftrace/Makefile >> index 76cc9f1..7c7cf42 100644 >> --- a/tools/testing/selftests/ftrace/Makefile >> +++ b/tools/testing/selftests/ftrace/Makefile >> @@ -1,7 +1,16 @@ >> +TEST_STR = /bin/sh ./ftracetest || echo ftrace selftests: [FAIL] > > Is it ok that this removes the quotes around the echo string? I don't > see anything wrong about it, but I don't know if there's a shell out > there that will fail due to it. Agreed, if possible, we'd better add quotes around the echo string as you did in 2/20 in this series. Anyway, you can also add my ack to this patch. Acked-by: Masami Hiramatsu Thank you! > > Other than than, > > Acked-by: Steven Rostedt > > -- Steve > > >> + >> all: >> >> +install: >> +ifdef INSTALL_KSFT_PATH >> +install ./ftracetest $(INSTALL_KSFT_PATH) >> +@cp -r test.d $(INSTALL_KSFT_PATH) >> +echo "$(TEST_STR)" >> $(KSELFTEST) >> +endif >> + >> run_tests: >> -@/bin/sh ./ftracetest || echo "ftrace selftests: [FAIL]" >> +@$(TEST_STR) >> >> clean: >> rm -rf logs/* > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v18 11/11] ARM: optprobes: execute instruction during restoring if possible.
(2014/12/29 13:07), Wang Nan wrote:
> This patch removes software emulation or simulation for most of probed
> instructions. If the instruction doesn't use PC relative addressing,
> it will be translated into following instructions in the restore code
> in code template:
>
> ldmia {r0 - r14} // restore all instruction except PC
> // direct execute the probed instruction
> b next_insn // branch to next instruction.
>
> Signed-off-by: Wang Nan
Reviewed-by: Masami Hiramatsu
[...]
> /*
> + * See register_usage_mask. If the probed instruction doesn't use PC,
> + * we can copy it into template and have it executed directly without
> + * simulation or emulation.
> + */
> +#define can_kprobe_direct_exec(m)(!((m) & __register_usage_mask(15)))
BTW, is there any macro which indicates 15 is the number of PC register?
If we can do something like below, it will be easier to understand.
#define can_kprobe_direct_exec(m) (!test_bit(ARM_REG_PC/* == 15*/, ))
Thank you,
> +
> +/*
> * NOTE: the first sub and add instruction will be modified according
> * to the stack cost of the instruction.
> */
> @@ -66,7 +73,15 @@ asm (
> " orrne r2, #1\n"
> " strne r2, [sp, #60] @ set bit0 of PC for
> thumb\n"
> " msr cpsr_cxsf, r1\n"
> + ".global optprobe_template_restore_begin\n"
> + "optprobe_template_restore_begin:\n"
> " ldmia sp, {r0 - r15}\n"
> + ".global optprobe_template_restore_orig_insn\n"
> + "optprobe_template_restore_orig_insn:\n"
> + " nop\n"
> + ".global optprobe_template_restore_end\n"
> + "optprobe_template_restore_end:\n"
> + " nop\n"
> ".global optprobe_template_val\n"
> "optprobe_template_val:\n"
> "1: .long 0\n"
> @@ -86,6 +101,12 @@ asm (
> ((unsigned long *)_template_add_sp - (unsigned long
> *)_template_entry)
> #define TMPL_SUB_SP \
> ((unsigned long *)_template_sub_sp - (unsigned long
> *)_template_entry)
> +#define TMPL_RESTORE_BEGIN \
> + ((unsigned long *)_template_restore_begin - (unsigned long
> *)_template_entry)
> +#define TMPL_RESTORE_ORIGN_INSN \
> + ((unsigned long *)_template_restore_orig_insn - (unsigned long
> *)_template_entry)
> +#define TMPL_RESTORE_END \
> + ((unsigned long *)_template_restore_end - (unsigned long
> *)_template_entry)
>
> /*
> * ARM can always optimize an instruction when using ARM ISA, except
> @@ -155,8 +176,12 @@ optimized_callback(struct optimized_kprobe *op, struct
> pt_regs *regs)
> __this_cpu_write(current_kprobe, NULL);
> }
>
> - /* In each case, we must singlestep the replaced instruction. */
> - op->kp.ainsn.insn_singlestep(p->opcode, >ainsn, regs);
> + /*
> + * We singlestep the replaced instruction only when it can't be
> + * executed directly during restore.
> + */
> + if (!p->ainsn.kprobe_direct_exec)
> + op->kp.ainsn.insn_singlestep(p->opcode, >ainsn, regs);
>
> local_irq_restore(flags);
> }
> @@ -238,6 +263,28 @@ int arch_prepare_optimized_kprobe(struct
> optimized_kprobe *op, struct kprobe *or
> val = (unsigned long)optimized_callback;
> code[TMPL_CALL_IDX] = val;
>
> + /* If possible, copy insn and have it executed during restore */
> + orig->ainsn.kprobe_direct_exec = false;
> + if (can_kprobe_direct_exec(orig->ainsn.register_usage_mask)) {
> + kprobe_opcode_t final_branch = arm_gen_branch(
> + (unsigned long)([TMPL_RESTORE_END]),
> + (unsigned long)(op->kp.addr) + 4);
> + if (final_branch != 0) {
> + /*
> + * Replace original 'ldmia sp, {r0 - r15}' with
> + * 'ldmia {r0 - r14}', restore all registers except pc.
> + */
> + code[TMPL_RESTORE_BEGIN] =
> __opcode_to_mem_arm(0xe89d7fff);
> +
> + /* The original probed instruction */
> + code[TMPL_RESTORE_ORIGN_INSN] =
> __opcode_to_mem_arm(orig->opcode);
> +
> + /* Jump back to next instruction */
> + code[TMPL_RESTORE_END] =
> __opcode_to_mem_arm(final_branch);
> + orig->ainsn.kprobe_direct_exec = true;
> + }
> + }
> +
> flush_icache_range((unsigned long)code,
> (unsigned long)([TMPL_END_IDX]));
>
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Re: Re: [PATCH v3 05/20] selftests/ftrace: add install target to enable test install
(2015/01/03 0:45), Steven Rostedt wrote: > On Wed, 24 Dec 2014 09:27:41 -0700 > Shuah Khan wrote: > >> Add a new make target to enable installing test. This target >> installs test in the kselftest install location and add to the >> kselftest script to run the test. Install target can be run >> only from top level kernel source directory. >> >> Signed-off-by: Shuah Khan >> --- >> tools/testing/selftests/ftrace/Makefile | 11 ++- >> 1 file changed, 10 insertions(+), 1 deletion(-) >> >> diff --git a/tools/testing/selftests/ftrace/Makefile >> b/tools/testing/selftests/ftrace/Makefile >> index 76cc9f1..7c7cf42 100644 >> --- a/tools/testing/selftests/ftrace/Makefile >> +++ b/tools/testing/selftests/ftrace/Makefile >> @@ -1,7 +1,16 @@ >> +TEST_STR = /bin/sh ./ftracetest || echo ftrace selftests: [FAIL] > > Is it ok that this removes the quotes around the echo string? I don't > see anything wrong about it, but I don't know if there's a shell out > there that will fail due to it. Agreed, if possible, we'd better add quotes around the echo string as you did in 2/20 in this series. Anyway, you can also add my ack to this patch. Acked-by: Masami Hiramatsu Thank you! > > Other than than, > > Acked-by: Steven Rostedt > > -- Steve > > >> + >> all: >> >> +install: >> +ifdef INSTALL_KSFT_PATH >> +install ./ftracetest $(INSTALL_KSFT_PATH) >> +@cp -r test.d $(INSTALL_KSFT_PATH) >> +echo "$(TEST_STR)" >> $(KSELFTEST) >> +endif >> + >> run_tests: >> -@/bin/sh ./ftracetest || echo "ftrace selftests: [FAIL]" >> +@$(TEST_STR) >> >> clean: >> rm -rf logs/* > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v18 10/11] ARM: kprobes: check register usage for probed instruction.
On 2015/1/4 13:05, Masami Hiramatsu wrote:
> Hi Wang,
>
> (2014/12/29 13:07), Wang Nan wrote:
>> This patch utilizes previous introduced checker to check register usage
>> for probed ARM instruction and saves it in a mask. Futher patch will
>> use such information to avoid simuation or emulation.
>>
>> Signed-off-by: Wang Nan
>> ---
>> arch/arm/include/asm/probes.h | 12
>> arch/arm/probes/decode.c | 7 ++
>> arch/arm/probes/kprobes/actions-arm.c | 2 +-
>> arch/arm/probes/kprobes/checkers-arm.c | 124
>> +
>> arch/arm/probes/kprobes/checkers.h | 1 +
>> 5 files changed, 145 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/asm/probes.h b/arch/arm/include/asm/probes.h
>> index f0a1ee8..ee04067 100644
>> --- a/arch/arm/include/asm/probes.h
>> +++ b/arch/arm/include/asm/probes.h
>> @@ -41,6 +41,18 @@ struct arch_probes_insn {
>> probes_insn_singlestep_t*insn_singlestep;
>> probes_insn_fn_t*insn_fn;
>> int stack_space;
>> +
>> +/* Use 2 bits for a register. One more bit for extension */
>
> Would you have any concrete idea for the extend bits? If not, we don't need
> it at this point. I think we don't need to care about future binary
> compatibility :)
> (moreover, if you need another bitflag, you can add another flag)
>
2 bits can describe the read/write direction of a register. With such
information,
futher code is possible to utilize unused register to do some optimization.
However,
as you pointed, it is not a very concrete idea.
>> +#define REG_NO_USE (0)
>> +#define REG_USE (1)
>> +#define REG_MASK(3)
>> +#define __register_usage_flag(n, f) ((f) << ((n) * 2))
>> +#define __register_usage_mask(n)(REG_MASK << ((n) * 2))
>> +#define __clean_register_flag(m, n) ((m) & (~(__register_usage_mask(n
>> +#define __set_register_flag(m, n, f)(__clean_register_flag(m, n) |
>> __register_usage_flag(n, f))
>> +#define set_register_nouse(m, n)do {(m) = __set_register_flag(m, n,
>> REG_NO_USE);} while(0)
>> +#define set_register_use(m, n) do {(m) =
>> __set_register_flag(m, n, REG_USE);} while(0)
>> +int register_usage_mask;
>
> Is this a mask or flag? It seems a bit flag, if so, it should be
> "register_usage_flag".
>
> Thank you,
>
OK, I'll rename it.
Thanks to your comment.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v18 10/11] ARM: kprobes: check register usage for probed instruction.
Hi Wang,
(2014/12/29 13:07), Wang Nan wrote:
> This patch utilizes previous introduced checker to check register usage
> for probed ARM instruction and saves it in a mask. Futher patch will
> use such information to avoid simuation or emulation.
>
> Signed-off-by: Wang Nan
> ---
> arch/arm/include/asm/probes.h | 12
> arch/arm/probes/decode.c | 7 ++
> arch/arm/probes/kprobes/actions-arm.c | 2 +-
> arch/arm/probes/kprobes/checkers-arm.c | 124
> +
> arch/arm/probes/kprobes/checkers.h | 1 +
> 5 files changed, 145 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/probes.h b/arch/arm/include/asm/probes.h
> index f0a1ee8..ee04067 100644
> --- a/arch/arm/include/asm/probes.h
> +++ b/arch/arm/include/asm/probes.h
> @@ -41,6 +41,18 @@ struct arch_probes_insn {
> probes_insn_singlestep_t*insn_singlestep;
> probes_insn_fn_t*insn_fn;
> int stack_space;
> +
> + /* Use 2 bits for a register. One more bit for extension */
Would you have any concrete idea for the extend bits? If not, we don't need
it at this point. I think we don't need to care about future binary
compatibility :)
(moreover, if you need another bitflag, you can add another flag)
> +#define REG_NO_USE (0)
> +#define REG_USE (1)
> +#define REG_MASK (3)
> +#define __register_usage_flag(n, f) ((f) << ((n) * 2))
> +#define __register_usage_mask(n) (REG_MASK << ((n) * 2))
> +#define __clean_register_flag(m, n) ((m) & (~(__register_usage_mask(n
> +#define __set_register_flag(m, n, f) (__clean_register_flag(m, n) |
> __register_usage_flag(n, f))
> +#define set_register_nouse(m, n) do {(m) = __set_register_flag(m, n,
> REG_NO_USE);} while(0)
> +#define set_register_use(m, n) do {(m) =
> __set_register_flag(m, n, REG_USE);} while(0)
> + int register_usage_mask;
Is this a mask or flag? It seems a bit flag, if so, it should be
"register_usage_flag".
Thank you,
> };
>
> #endif /* __ASSEMBLY__ */
> diff --git a/arch/arm/probes/decode.c b/arch/arm/probes/decode.c
> index f9d7c42..d60a1b2 100644
> --- a/arch/arm/probes/decode.c
> +++ b/arch/arm/probes/decode.c
> @@ -435,6 +435,13 @@ probes_decode_insn(probes_opcode_t insn, struct
> arch_probes_insn *asi,
>*/
> asi->stack_space = 0;
>
> + /*
> + * Similay to stack_space, register_usage_mask is filled by
> + * checkers. Its default value is set to ~0, which is 'all
> + * registers are used', to prevent any potential optimization.
> + */
> + asi->register_usage_mask = ~(0UL);
> +
> if (emulate)
> insn = prepare_emulated_insn(insn, asi, thumb);
>
> diff --git a/arch/arm/probes/kprobes/actions-arm.c
> b/arch/arm/probes/kprobes/actions-arm.c
> index 4fedd4c..26e435b 100644
> --- a/arch/arm/probes/kprobes/actions-arm.c
> +++ b/arch/arm/probes/kprobes/actions-arm.c
> @@ -340,4 +340,4 @@ const union decode_action
> kprobes_arm_actions[NUM_PROBES_ARM_ACTIONS] = {
> [PROBES_LDMSTM] = {.decoder = kprobe_decode_ldmstm}
> };
>
> -const struct decode_checker *kprobes_arm_checkers[] = {arm_stack_checker,
> NULL};
> +const struct decode_checker *kprobes_arm_checkers[] = {arm_stack_checker,
> arm_regs_checker, NULL};
> diff --git a/arch/arm/probes/kprobes/checkers-arm.c
> b/arch/arm/probes/kprobes/checkers-arm.c
> index f817663..df1d77b 100644
> --- a/arch/arm/probes/kprobes/checkers-arm.c
> +++ b/arch/arm/probes/kprobes/checkers-arm.c
> @@ -97,3 +97,127 @@ const struct decode_checker
> arm_stack_checker[NUM_PROBES_ARM_ACTIONS] = {
> [PROBES_STORE] = {.checker = arm_check_stack},
> [PROBES_LDMSTM] = {.checker = arm_check_stack},
> };
> +
> +static enum probes_insn __kprobes arm_check_regs_nouse(probes_opcode_t insn,
> + struct arch_probes_insn *asi,
> + const struct decode_header *h)
> +{
> + asi->register_usage_mask = 0;
> + return INSN_GOOD;
> +}
> +
> +static void __arm_check_regs(probes_opcode_t insn,
> + const struct decode_header *h,
> + int *quintuple)
> +{
> + int i;
> + u32 regs = h->type_regs.bits >> DECODE_TYPE_BITS;
> + probes_opcode_t mask, shifted;
> +
> + memset(quintuple, 0xff, sizeof(int) * 5);
> + for (i = 0, shifted = insn, mask = 0xf; regs != 0;
> + regs >>= 4, mask <<= 4, shifted >>= 4, i++)
> + if (regs & 0xf)
> + quintuple[i] = shifted & 0xf;
> +}
> +
> +static enum probes_insn arm_check_regs_normal(probes_opcode_t insn,
> + struct arch_probes_insn *asi,
> + const struct decode_header *h)
> +{
> + int quintuple[5], i;
> + asi->register_usage_mask = 0;
> + __arm_check_regs(insn, h, quintuple);
> + for (i = 0; i < 5; i++) {
> + int r = quintuple[i];
> + if (r < 0)
> + continue;
> +
Re: Re: [PATCH] [BUGFIX] perf-probe: Fix to fall back to find probe point in symbols
(2014/12/31 17:02), Namhyung Kim wrote:
> Hi Masami,
>
> On Wed, Dec 31, 2014 at 03:27:47PM +0900, Masami Hiramatsu wrote:
>> Fix to fall back to find a probe point in symbols if perf fails
>> to find it in debuginfo.
>>
>> This can happen when the target function is an alias of another
>> function. Such alias doesn't have an entry in debuginfo but in
>> symbols.
>>
>> David Ahern reported this problem in https://lkml.org/lkml/2014/12/29/355
>>
>> I ensured the problem and deeper investigation discovers it.
>> -
>> eu-readelf --debug-dump=info
>> /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so | grep \"malloc\" -A6
>> name (strp) "malloc"
>> decl_file(data1) 25
>> decl_line(data2) 466
>> prototyped (flag_present)
>> type (ref4) [ 81b5]
>> declaration (flag_present)
>> [ 8f58] formal_parameter
>> --
>> name (strp) "malloc"
>> decl_file(data1) 23
>> decl_line(data2) 466
>> prototyped (flag_present)
>> type (ref4) [ 9f4a]
>> declaration (flag_present)
>> sibling (ref4) [ bb29]
>> ...
>> -
>> All these entires have no instances (all of them are declarations)
>> This is why the perf probe failed to find it in debuginfo.
>>
>> However, there are some malloc instances in symbols.
>> -
>> eu-readelf --symbols /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so |
>> grep malloc$
>> 1181: 00080700 5332 FUNCLOCAL DEFAULT 12 _int_malloc
>> 4537: 000831d0339 FUNCLOCAL DEFAULT 12
>> __GI___libc_malloc
>> 5545: 000831d0339 FUNCLOCAL DEFAULT 12 __malloc
>> 6063: 000831d0339 FUNCGLOBAL DEFAULT 12 malloc
>> 7302: 000831d0339 FUNCGLOBAL DEFAULT 12 __libc_malloc
>> -
>> As you an see, malloc and __libc_malloc have same address, and actually
>> __libc_malloc has an entry in debuginfo. So you can set up a probe on
>> __libc_malloc.
>>
>> To fix this problem shortly, perf probe simply falls back to find probe
>> point(malloc) in symbols if it is not found in debuginfo.
>
> Idealy, it'd be great if it can go to the definition. I think perf
> only keeps a single symbol at a same address so if there're multiple
> aliases at a specific address it might be missed even with this patch.
Hmm, anyway, that should be fixed by improving perf's map, instead of
introducing new symbol finder.
> But that will be a rare case, so
>
> Acked-by: Namhyung Kim
Thank you!
>
> Thanks,
> Namhyung
>
>
>>
>> Signed-off-by: Masami Hiramatsu
>> Reported-by: David Ahern
>> ---
>> tools/perf/util/probe-event.c |6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
>> index 28eb141..7f9b863 100644
>> --- a/tools/perf/util/probe-event.c
>> +++ b/tools/perf/util/probe-event.c
>> @@ -495,9 +495,11 @@ static int try_to_find_probe_trace_events(struct
>> perf_probe_event *pev,
>> }
>>
>> if (ntevs == 0) { /* No error but failed to find probe point. */
>> -pr_warning("Probe point '%s' not found.\n",
>> +pr_warning("Probe point '%s' not found in debuginfo.\n",
>> synthesize_perf_probe_point(>point));
>> -return -ENOENT;
>> +if (need_dwarf)
>> +return -ENOENT;
>> +return 0;
>> }
>> /* Error path : ntevs < 0 */
>> pr_debug("An error occurred in debuginfo analysis (%d).\n", ntevs);
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@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/
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irq: irq-hip04: initialize hip04_cpu_map to 0xffff
On 2014/12/11 19:19, Haojian Zhuang wrote: > On 11 December 2014 at 19:03, Wang Long wrote: >> HiP04 GIC extends to support 16 cores, so we should >> initialize the hip04_cpu_map to 0x. >> >> Signed-off-by: Wang Long >> --- >> drivers/irqchip/irq-hip04.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/irqchip/irq-hip04.c b/drivers/irqchip/irq-hip04.c >> index 9c8f8335..8eee46b 100644 >> --- a/drivers/irqchip/irq-hip04.c >> +++ b/drivers/irqchip/irq-hip04.c >> @@ -382,7 +382,7 @@ hip04_of_init(struct device_node *node, struct >> device_node *parent) >> * It will be refined as each CPU probes its ID. >> */ >> for (i = 0; i < NR_HIP04_CPU_IF; i++) >> - hip04_cpu_map[i] = 0xff; >> + hip04_cpu_map[i] = 0x; >> >> /* >> * Find out how many interrupts are supported. >> -- >> 1.8.3.4 >> > > Acked-by: Haojian Zhuang > > Best Regards > Haojian > > hi Thomas Gleixner, Jason Cooper could you please help to apply this patch? Best Regards Wang Long -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH] f2fs: add extent cache base on rb-tree
Hi Changman,
Sorry for replying late!
> -Original Message-
> From: Changman Lee [mailto:cm224@samsung.com]
> Sent: Tuesday, December 30, 2014 8:32 AM
> To: Jaegeuk Kim
> Cc: Chao Yu; linux-f2fs-de...@lists.sourceforge.net;
> linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH] f2fs: add extent cache base on rb-tree
>
> Hi all,
>
> On Mon, Dec 29, 2014 at 01:23:00PM -0800, Jaegeuk Kim wrote:
> > Hi Chao,
> >
> > On Mon, Dec 29, 2014 at 03:19:18PM +0800, Chao Yu wrote:
> >
> > [snip]
> >
> > Nice draft. :)
> >
> > >
> > > Please see the draft below.
> > >
> > > 1) Extent management:
> > > If we use global management that managing all extents which are from
> > > different
> > > inodes in sbi, we will face with serious lock contention when we access
> > > these
> > > extents belong to different inodes concurrently, the loss may outweights
> > > the
> > > gain.
> >
> > Agreed.
> >
> > > So we choose a local management for extent which means all extents are
> > > managed by inode itself to avoid above lock contention. Addtionlly, we
> > > manage
> > > all extents globally by linking all inode into a global lru list for
> > > extent
> > > cache shrinker.
> > > Approach:
> > > a) build extent tree/rwlock/lru list/extent count in each inode.
> > > *extent tree: link all extent in rb-tree;
> > > *rwlock: protect fields when accessing extent cache
> > > concurrently;
> > > *lru list: sort all extents in accessing time order;
> > > *extent count: record total count of extents in cache.
> > > b) use lru shrink list in sbi to manage all inode which cached extents.
> > > *inode will be added or repostioned in this global list whenever
> > > extent is being access in this inode.
> > > *use spinlock to protect this shrink list.
> >
> > 1. How about adding a data structure with inode number instead of referring
> > inode pointer?
> >
> > 2. How about managing extent entries globally and setting an upper bound to
> > the number of extent entries instead of limiting them per each inode?
> > (The rb-tree will handle many extents per inode.)
> >
> > 3. It needs to set a minimum length for the candidate of extent cache.
> > (e.g., 64)
> >
>
> Agreed.
>
> > So, for example,
> > struct ino_entry_for_extents {
> > inode number;
> > rb_tree for extent_entry objects;
> > rwlock;
> > };
> >
> > struct extent_entry {
> > blkaddr, len;
> > list_head *;
> > };
> >
> > Something like this.
> >
> > [A, B, C, ... are extent entry]
> >
> > The sbi has
> > 1. an extent_list: (LRU) A -> B -> C -> D -> E -> F -> G (MRU)
> > 2. radix_tree: ino_entry_for_extents (#10) has D, B in rb-tree
> > ` ino_entry_for_extents (#11) has A, C in rb-tree
> > ` ino_entry_for_extents (#12) has Fin rb-tree
> > ` ino_entry_for_extents (#13) has G, E in rb-tree
> >
> > In f2fs_update_extent_cache and __get_data_block for #10,
> > ino_entry_for_extents (#10) was founded and updated D or B.
> > Then, updated entries are moved to MRU.
> >
> > In f2fs_evict_inode for #11, A and C are moved to LRU.
> > But, if this inode is unlinked, all the A, C, and ino_entry_for_extens (#11)
> > should be released.
> >
> > In f2fs_balance_fs_bg, some LRU extents are released according to the amount
> > of consumed memory. Then, it frees any ino_entry_for_extents having no
> > extent.
> >
> > IMO, we don't need to consider readahead for this, since get_data_block will
> > be called by VFS readahead.
> >
> > Furthermore, we need to think about whether LRU is really best or not.
> > IMO, the extent cache aims to improve second access speed, rather than
> > initial
> > cold misses. So, maybe MRU or another algorithms would be better.
> >
>
> Right. It's very comflicated to judge which is better.
> In read or write path, extents could be made every time. At that time, we
> should
> decide which extent evicts instead of new extents if we set upper bound.
> In update, one extent could be seperated into 3. It requires 3 insertion and
> 1 deletion.
> So if update happends frequently, we could give up extent management for some
> ranges.
> And we need to bring ideas from vm managemnt. For example,
> active/inactive list and second chance to promotion, or batch work for
> insertion/deletion
>
> I thought suddenly 'Simple is best'.
> Let's think about better ideas together.
Yeah, how about using an opposite way to the way of page cache manager?
for example:
node page A,B,C,D is in page cache;
extent a,b,c,d is in extent cache;
extent a is built from page A, ..., d is built from page D.
page cache: LRU A -> B -> C -> D MRU
extent cache: LRU a -> b -> c -> d MRU
If we use
1) the same way LRU, cache pair A-a, B-b, ... may be reclaimed in the same time
as OOM.
2) the opposite way, maybe A,B in page cache and d,c in extent cache will be
reclaimed,
but we still can hit whole cache in combination of page cache and
Re: [PATCH] ovl: Prevent rw remount when it should be ro mount
On 2015/1/3 1:26, Seunghun Lee wrote:
> Overlayfs should be mounted read-only when upper-fs is read-only or
> nonexistent.
> But now it can be remounted read-write and this can cause kernel panic.
> So we should prevent read-write remount when the above situation happens.
>
> Signed-off-by: Seunghun Lee
> ---
> fs/overlayfs/super.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
> index 84f3144..8944651 100644
> --- a/fs/overlayfs/super.c
> +++ b/fs/overlayfs/super.c
> @@ -522,10 +522,21 @@ static int ovl_show_options(struct seq_file *m, struct
> dentry *dentry)
> return 0;
> }
>
> +static int ovl_remount(struct super_block *sb, int *flags, char *data)
> +{
> + struct ovl_fs *ufs = sb->s_fs_info;
> +
> + if (!ufs->upper_mnt || (ufs->upper_mnt->mnt_sb->s_flags & MS_RDONLY))
> + *flags |= MS_RDONLY;
> +
> + return 0;
> +}
> +
> static const struct super_operations ovl_super_operations = {
> .put_super = ovl_put_super,
> .statfs = ovl_statfs,
> .show_options = ovl_show_options,
> + .remount_fs = ovl_remount,
> };
>
> enum {
>
I think this exporting of .remount_fs may allow people in userspace
have the ability to remount a filesystem with a new set of mounting
options. Your new adding function do nothing with the passing in
parameters.
I'm not sure if it could be competent for remount case.
Add Cc linux-unionfs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[LKP] [net/socket.c ] 0cf00c6f360: -3.1% netperf.Throughput_Mbps
FYI, we noticed the below changes on
commit 0cf00c6f360a3f7b97be000520f1acde88800536 ("net/socket.c : introduce
helper function do_sock_sendmsg to replace reduplicate code")
testbox/testcase/testparams:
lkp-t410/netperf/performance-300s-200%-10K-SCTP_STREAM_MANY
42eef7a0bb0989cd 0cf00c6f360a3f7b97be000520
--
%stddev %change %stddev
\ |\
1293786 ± 4% -17.0%1073209 ± 4%
netperf.time.voluntary_context_switches
13.73 ± 3% -8.2% 12.61 ± 1% netperf.time.user_time
1198 ± 0% -3.1% 1162 ± 0% netperf.Throughput_Mbps
220 ± 0% -2.8%214 ± 0%
netperf.time.percent_of_cpu_this_job_got
653 ± 0% -2.7%635 ± 0% netperf.time.system_time
5.91 ± 22%-100.0% 0.00 ± 0%
perf-profile.cpu-cycles._raw_spin_unlock_bh.release_sock.sctp_sendmsg.inet_sendmsg.sock_sendmsg
0 ± 0% +Inf%131 ± 1%
latency_stats.avg.sctp_sendmsg.[sctp].inet_sendmsg.do_sock_sendmsg.___sys_sendmsg.__sys_sendmsg.SyS_sendmsg.system_call_fastpath
0 ± 0% +Inf% 4976 ± 0%
latency_stats.max.sctp_sendmsg.[sctp].inet_sendmsg.do_sock_sendmsg.___sys_sendmsg.__sys_sendmsg.SyS_sendmsg.system_call_fastpath
15.58 ± 5%-100.0% 0.00 ± 0%
perf-profile.cpu-cycles.sctp_datamsg_from_user.sctp_sendmsg.inet_sendmsg.sock_sendmsg.___sys_sendmsg
21.57 ± 6%-100.0% 0.00 ± 0%
perf-profile.cpu-cycles.sctp_primitive_SEND.sctp_sendmsg.inet_sendmsg.sock_sendmsg.___sys_sendmsg
21.10 ± 6%-100.0% 0.00 ± 0%
perf-profile.cpu-cycles.release_sock.sctp_sendmsg.inet_sendmsg.sock_sendmsg.___sys_sendmsg
62.06 ± 2%-100.0% 0.00 ± 0%
perf-profile.cpu-cycles.sctp_sendmsg.inet_sendmsg.sock_sendmsg.___sys_sendmsg.__sys_sendmsg
62.68 ± 2%-100.0% 0.00 ± 0%
perf-profile.cpu-cycles.inet_sendmsg.sock_sendmsg.___sys_sendmsg.__sys_sendmsg.sys_sendmsg
63.26 ± 2%-100.0% 0.00 ± 0%
perf-profile.cpu-cycles.sock_sendmsg.___sys_sendmsg.__sys_sendmsg.sys_sendmsg.system_call_fastpath
0 ± 0% +Inf%1068435 ± 4%
latency_stats.hits.sctp_sendmsg.[sctp].inet_sendmsg.do_sock_sendmsg.___sys_sendmsg.__sys_sendmsg.SyS_sendmsg.system_call_fastpath
14.88 ± 1%-100.0% 0.00 ± 0%
perf-profile.cpu-cycles.sctp_backlog_rcv.release_sock.sctp_sendmsg.inet_sendmsg.sock_sendmsg
12.33 ± 4%-100.0% 0.00 ± 0%
perf-profile.cpu-cycles.sctp_do_sm.sctp_primitive_SEND.sctp_sendmsg.inet_sendmsg.sock_sendmsg
0 ± 0% +Inf% 1.404e+08 ± 3%
latency_stats.sum.sctp_sendmsg.[sctp].inet_sendmsg.do_sock_sendmsg.___sys_sendmsg.__sys_sendmsg.SyS_sendmsg.system_call_fastpath
8.68 ± 5%-100.0% 0.00 ± 0%
perf-profile.cpu-cycles.sctp_user_addto_chunk.sctp_datamsg_from_user.sctp_sendmsg.inet_sendmsg.sock_sendmsg
5.78 ± 6%-100.0% 0.00 ± 0%
perf-profile.cpu-cycles.sctp_make_datafrag_empty.sctp_datamsg_from_user.sctp_sendmsg.inet_sendmsg.sock_sendmsg
4960 ± 1%-100.0% 0 ± 0%
latency_stats.max.sctp_sendmsg.[sctp].inet_sendmsg.sock_sendmsg.___sys_sendmsg.__sys_sendmsg.SyS_sendmsg.system_call_fastpath
135 ± 3%-100.0% 0 ± 0%
latency_stats.avg.sctp_sendmsg.[sctp].inet_sendmsg.sock_sendmsg.___sys_sendmsg.__sys_sendmsg.SyS_sendmsg.system_call_fastpath
1.755e+08 ± 5%-100.0% 0 ± 0%
latency_stats.sum.sctp_sendmsg.[sctp].inet_sendmsg.sock_sendmsg.___sys_sendmsg.__sys_sendmsg.SyS_sendmsg.system_call_fastpath
1289900 ± 4%-100.0% 0 ± 0%
latency_stats.hits.sctp_sendmsg.[sctp].inet_sendmsg.sock_sendmsg.___sys_sendmsg.__sys_sendmsg.SyS_sendmsg.system_call_fastpath
0.00 ± 0% +Inf% 5.88 ± 9%
perf-profile.cpu-cycles._raw_spin_unlock_bh.release_sock.sctp_sendmsg.inet_sendmsg.do_sock_sendmsg
0.00 ± 0% +Inf% 6.16 ± 0%
perf-profile.cpu-cycles.sctp_make_datafrag_empty.sctp_datamsg_from_user.sctp_sendmsg.inet_sendmsg.do_sock_sendmsg
0.00 ± 0% +Inf% 8.69 ± 0%
perf-profile.cpu-cycles.sctp_user_addto_chunk.sctp_datamsg_from_user.sctp_sendmsg.inet_sendmsg.do_sock_sendmsg
0.00 ± 0% +Inf% 12.81 ± 3%
perf-profile.cpu-cycles.sctp_do_sm.sctp_primitive_SEND.sctp_sendmsg.inet_sendmsg.do_sock_sendmsg
0.00 ± 0% +Inf% 22.40 ± 4%
perf-profile.cpu-cycles.sctp_primitive_SEND.sctp_sendmsg.inet_sendmsg.do_sock_sendmsg.___sys_sendmsg
0.00 ± 0% +Inf% 16.02 ± 0%
perf-profile.cpu-cycles.sctp_datamsg_from_user.sctp_sendmsg.inet_sendmsg.do_sock_sendmsg.___sys_sendmsg
0.00 ± 0% +Inf% 20.81 ± 3%
perf-profile.cpu-cycles.release_sock.sctp_sendmsg.inet_sendmsg.do_sock_sendmsg.___sys_sendmsg
0.00 ± 0% +Inf% 64.24 ± 2%
[PATCH 1/2] Chipidea: TI-NSPIRE USB OTG hardware does not support high speed and must connect at full speed
Signed-off-by: Daniel Tang
---
drivers/usb/chipidea/ci_hdrc_zevio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_zevio.c
b/drivers/usb/chipidea/ci_hdrc_zevio.c
index d976fc1..1264de5 100644
--- a/drivers/usb/chipidea/ci_hdrc_zevio.c
+++ b/drivers/usb/chipidea/ci_hdrc_zevio.c
@@ -18,7 +18,7 @@
static struct ci_hdrc_platform_data ci_hdrc_zevio_platdata = {
.name = "ci_hdrc_zevio",
- .flags = CI_HDRC_REGS_SHARED,
+ .flags = CI_HDRC_REGS_SHARED | CI_HDRC_FORCE_FULLSPEED,
.capoffset = DEF_CAPOFFSET,
};
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Chipidea: Set connect-at-fullspeed bit when entering host mode if CI_HDRC_FORCE_FULLSPEED is set in the platform data
PORTSC_PFSC is not set on entering host mode which means the USB OTG controller will attempt to enumerate USB devices at high speed even when the CI_HDRC_FORCE_FULLSPEED flag is set in the platform data. This patch ensures it is set right before host mode operations begin if needed. Signed-off-by: Daniel Tang --- drivers/usb/chipidea/host.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c index c1694cf..f106d25 100644 --- a/drivers/usb/chipidea/host.c +++ b/drivers/usb/chipidea/host.c @@ -132,6 +132,9 @@ static int host_start(struct ci_hdrc *ci) if (ci->platdata->flags & CI_HDRC_DISABLE_STREAMING) hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS, USBMODE_CI_SDIS); + if (ci->platdata->flags & CI_HDRC_FORCE_FULLSPEED) + hw_write(ci, OP_PORTSC, PORTSC_PFSC, PORTSC_PFSC); + return ret; put_hcd: -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 0002-Spi-spi-gpio-fixed-spaces-coding-style-issue.patch
Nizam,
You made a lot of mistakes in this patch submission :(
Specifically, you should never include a patch as an attachment [2],
and your subject line should say [PATCH] [2].
If you want to learn how to correctly submit patches I recommend
watching this [1], reading this [2], and signing up for this [3].
[1]: https://www.youtube.com/watch?v=LLBrBBImJt4
[2]: https://www.kernel.org/doc/Documentation/SubmittingPatches
[3]: http://www.eudyptula-challenge.org/
On Sun, Jan 04, 2015 at 01:27:40AM +0530, Nizam Haider wrote:
>
> From 00454f12a304489125bbdfbc2f50de3c2b9d49d3 Mon Sep 17 00:00:00 2001
> From: Nizam Haider
> Date: Sun, 4 Jan 2015 00:24:38 +0530
> Subject: [PATCH 2/2] Spi: spi-gpio: fixed spaces coding style issue
>
> Fixed a coding style issue.
>
> Signed-off-by: Nizam Haider
> ---
> drivers/spi/spi-gpio.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
> index aee4e75..702b0b8 100644
> --- a/drivers/spi/spi-gpio.c
> +++ b/drivers/spi/spi-gpio.c
> @@ -92,7 +92,7 @@ struct spi_gpio {
>
> /*--*/
>
> -static inline struct spi_gpio * __pure
> +static inline struct spi_gpio *__pure
> spi_to_spi_gpio(const struct spi_device *spi)
> {
> const struct spi_bitbang*bang;
> @@ -103,7 +103,7 @@ spi_to_spi_gpio(const struct spi_device *spi)
> return spi_gpio;
> }
>
> -static inline struct spi_gpio_platform_data * __pure
> +static inline struct spi_gpio_platform_data *__pure
> spi_to_pdata(const struct spi_device *spi)
> {
> return _to_spi_gpio(spi)->pdata;
> --
> 1.8.1.4
>
--
- Jeremiah Mahler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next] qlcnic: Fix dump_skb output
Use normal facilities to avoid printing each byte
on a separate line.
Now emits at KERN_DEBUG instead of KERN_INFO.
Signed-off-by: Joe Perches
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
index 18e5de7..d166e53 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "qlcnic.h"
@@ -1465,14 +1466,14 @@ void qlcnic_post_rx_buffers(struct qlcnic_adapter
*adapter,
static void dump_skb(struct sk_buff *skb, struct qlcnic_adapter *adapter)
{
- int i;
- unsigned char *data = skb->data;
-
- pr_info(KERN_INFO "\n");
- for (i = 0; i < skb->len; i++) {
- QLCDB(adapter, DRV, "%02x ", data[i]);
- if ((i & 0x0f) == 8)
- pr_info(KERN_INFO "\n");
+ if (adapter->ahw->msg_enable & NETIF_MSG_DRV) {
+ char prefix[30];
+
+ scnprintf(prefix, sizeof(prefix), "%s: %s: ",
+ dev_name(>pdev->dev), __func__);
+
+ print_hex_dump_debug(prefix, DUMP_PREFIX_NONE, 16, 1,
+skb->data, skb->len, true);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] *** SUBJECT HERE ***
On 01/03, Paul Bolle wrote: > On Sat, 2015-01-03 at 08:45 -0800, Greg KH wrote: > > On Sat, Jan 03, 2015 at 02:06:22PM +0530, jitendra kumar khasdev wrote: > > > *** BLURB HERE *** > > > > What blurb? What subject? > > jitendra used git-send-email to send this series. You'd expect > git-send-email to die with an error if the cover letter, which it should > see first, still contains these "*** [...] HERE ***" markers. What's the > reason it doesn't do that? git send-email does one thing and one thing only - sends stuff via email. I do not see why it should parse the emails and decide whether to complete the operation or break based on what is in the emails. It could warn though however since the cover letter is a product of different command introducing this logic would tightly couple those which is not good. I guess that it is better that people who send stuff acctually care what they are sending. I mean that pretty quickly you learn to send the series of patches first to yourself and review before it goes out to the public. > > Paul Bolle > > ___ > 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/
RE: [PATCH] soc: intel: sst-haswell-ipc: Remove some unused functions
Hi Rickard,
Thanks for your checking.
I have just confirmed that those functions really not used currently, although
they may be needed for advanced developing.
So, I have no objection if you remove them now.
Liam, what's your opinion?
~Keyon
> -Original Message-
> From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
> Sent: Sunday, January 04, 2015 8:35 AM
> To: Liam Girdwood; Mark Brown
> Cc: Rickard Strandqvist; Jaroslav Kysela; Takashi Iwai; Jie, Yang; Jarkko
> Nikula;
> Dan Carpenter; Christian Engelmayer; Piskorski, Pawel;
> alsa-de...@alsa-project.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] soc: intel: sst-haswell-ipc: Remove some unused functions
>
> Removes some functions that are not used anywhere:
> sst_hsw_stream_unmute() sst_hsw_stream_mute() msg_set_stage_type()
> sst_hsw_dx_get_state() sst_hsw_dx_set_state()
> sst_hsw_stream_set_write_position()
> sst_hsw_stream_get_vol_reg() sst_hsw_stream_get_peak_reg()
> sst_hsw_stream_get_pointer_reg() sst_hsw_stream_get_read_reg()
> sst_hsw_stream_get_mixer_id() sst_hsw_stream_get_hw_id()
> sst_hsw_mixer_set_volume_curve() sst_hsw_mixer_unmute()
> sst_hsw_mixer_mute()
> sst_hsw_stream_set_volume_curve()
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> sound/soc/intel/sst-haswell-ipc.c | 226
> -
> sound/soc/intel/sst-haswell-ipc.h | 34 --
> 2 files changed, 260 deletions(-)
>
> diff --git a/sound/soc/intel/sst-haswell-ipc.c
> b/sound/soc/intel/sst-haswell-ipc.c
> index b629151..26f856c 100644
> --- a/sound/soc/intel/sst-haswell-ipc.c
> +++ b/sound/soc/intel/sst-haswell-ipc.c
> @@ -333,12 +333,6 @@ static inline u32 msg_get_stage_type(u32 msg)
> return (msg & IPC_STG_TYPE_MASK) >> IPC_STG_TYPE_SHIFT; }
>
> -static inline u32 msg_set_stage_type(u32 msg, u32 type) -{
> - return (msg & ~IPC_STG_TYPE_MASK) +
> - (type << IPC_STG_TYPE_SHIFT);
> -}
> -
> static inline u32 msg_get_stream_id(u32 msg) {
> return (msg & IPC_STR_ID_MASK) >> IPC_STR_ID_SHIFT; @@ -965,45
> +959,6 @@ int sst_hsw_fw_get_version(struct sst_hsw *hsw, }
>
> /* Mixer Controls */
> -int sst_hsw_stream_mute(struct sst_hsw *hsw, struct sst_hsw_stream
> *stream,
> - u32 stage_id, u32 channel)
> -{
> - int ret;
> -
> - ret = sst_hsw_stream_get_volume(hsw, stream, stage_id, channel,
> - >mute_volume[channel]);
> - if (ret < 0)
> - return ret;
> -
> - ret = sst_hsw_stream_set_volume(hsw, stream, stage_id, channel, 0);
> - if (ret < 0) {
> - dev_err(hsw->dev, "error: can't unmute stream %d channel %d\n",
> - stream->reply.stream_hw_id, channel);
> - return ret;
> - }
> -
> - stream->mute[channel] = 1;
> - return 0;
> -}
> -
> -int sst_hsw_stream_unmute(struct sst_hsw *hsw, struct sst_hsw_stream
> *stream,
> - u32 stage_id, u32 channel)
> -
> -{
> - int ret;
> -
> - stream->mute[channel] = 0;
> - ret = sst_hsw_stream_set_volume(hsw, stream, stage_id, channel,
> - stream->mute_volume[channel]);
> - if (ret < 0) {
> - dev_err(hsw->dev, "error: can't unmute stream %d channel %d\n",
> - stream->reply.stream_hw_id, channel);
> - return ret;
> - }
> -
> - return 0;
> -}
> -
> int sst_hsw_stream_get_volume(struct sst_hsw *hsw, struct
> sst_hsw_stream *stream,
> u32 stage_id, u32 channel, u32 *volume) { @@ -1017,17 +972,6 @@ int
> sst_hsw_stream_get_volume(struct sst_hsw *hsw, struct sst_hsw_stream
> *stream
> return 0;
> }
>
> -int sst_hsw_stream_set_volume_curve(struct sst_hsw *hsw,
> - struct sst_hsw_stream *stream, u64 curve_duration,
> - enum sst_hsw_volume_curve curve)
> -{
> - /* curve duration in steps of 100ns */
> - stream->vol_req.curve_duration = curve_duration;
> - stream->vol_req.curve_type = curve;
> -
> - return 0;
> -}
> -
> /* stream volume */
> int sst_hsw_stream_set_volume(struct sst_hsw *hsw,
> struct sst_hsw_stream *stream, u32 stage_id, u32 channel, u32 volume)
> @@ -1065,42 +1009,6 @@ int sst_hsw_stream_set_volume(struct sst_hsw
> *hsw,
> return 0;
> }
>
> -int sst_hsw_mixer_mute(struct sst_hsw *hsw, u32 stage_id, u32 channel) -{
> - int ret;
> -
> - ret = sst_hsw_mixer_get_volume(hsw, stage_id, channel,
> - >mute_volume[channel]);
> - if (ret < 0)
> - return ret;
> -
> - ret = sst_hsw_mixer_set_volume(hsw, stage_id, channel, 0);
> - if (ret < 0) {
> - dev_err(hsw->dev, "error: failed to unmute mixer channel %d\n",
> - channel);
> - return ret;
> - }
> -
> - hsw->mute[channel] = 1;
> - return 0;
> -}
> -
> -int sst_hsw_mixer_unmute(struct sst_hsw *hsw, u32 stage_id, u32 channel) -{
> - int ret;
> -
> - ret =
Re: [PATCH] staging: gdm724x: fix coding style issues
On 01/03, Ning Zhou wrote:
> Signed-off-by: Ning Zhou
You need to describe your changes, a vague subject is not enough. Also
keep in mind that one patch shall address one category of stuff and
seems that yours could be separated into two.
thanks,
konrad
> ---
> drivers/staging/gdm724x/gdm_lte.c | 3 ++-
> drivers/staging/gdm724x/gdm_mux.c | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/gdm724x/gdm_lte.c
> b/drivers/staging/gdm724x/gdm_lte.c
> index 73eede1..7c4a77b 100644
> --- a/drivers/staging/gdm724x/gdm_lte.c
> +++ b/drivers/staging/gdm724x/gdm_lte.c
> @@ -281,7 +281,8 @@ static int gdm_lte_emulate_ndp(struct sk_buff *skb_in,
> u32 nic_type)
> icmp6_out.icmp6_type = NDISC_NEIGHBOUR_ADVERTISEMENT;
> icmp6_out.icmp6_code = 0;
> icmp6_out.icmp6_cksum = 0;
> - icmp6_out.icmp6_dataun.un_data32[0] = htonl(0x6000); /*
> R=0, S=1, O=1 */
> + /* R=0, S=1, O=1 */
> + icmp6_out.icmp6_dataun.un_data32[0] = htonl(0x6000);
>
> ns = (struct neighbour_solicitation *)
> (skb_in->data + mac_header_len +
> diff --git a/drivers/staging/gdm724x/gdm_mux.c
> b/drivers/staging/gdm724x/gdm_mux.c
> index b5b063a..d1ab996 100644
> --- a/drivers/staging/gdm724x/gdm_mux.c
> +++ b/drivers/staging/gdm724x/gdm_mux.c
> @@ -220,7 +220,7 @@ static int up_to_host(struct mux_rx *r)
> static void do_rx(struct work_struct *work)
> {
> struct mux_dev *mux_dev =
> - container_of(work, struct mux_dev , work_rx.work);
> + container_of(work, struct mux_dev, work_rx.work);
> struct mux_rx *r;
> struct rx_cxt *rx = (struct rx_cxt *)_dev->rx;
> unsigned long flags;
> --
> 1.9.1
>
> ___
> 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/
Re: [next-20141231] sched: WARNING: CPU: 1 PID: 2539 at kernel/sched/core.c:7303 __might_sleep+0xbd/0xd0()
Hi Sedat, On Sun, Jan 4, 2015 at 7:42 AM, Sedat Dilek wrote: > On Thu, Jan 1, 2015 at 11:28 AM, Sedat Dilek wrote: >> Hi, >> >> with next-20141231 I am seeing this call-trace: >> >> [ 88.028632] [ cut here ] >> [ 88.028643] WARNING: CPU: 1 PID: 2539 at kernel/sched/core.c:7303 >> __might_sleep+0xbd/0xd0() >> [ 88.028646] do not call blocking ops when !TASK_RUNNING; state=1 >> set at [] prepare_to_wait_event+0x5d/0x110 >> [ 88.028648] Modules linked in: ppp_deflate bsd_comp ppp_async >> crc_ccitt arc4 iwldvm uvcvideo mac80211 snd_hda_codec_hdmi >> snd_hda_codec_realtek parport_pc videobuf2_vmalloc >> snd_hda_codec_generic ppdev videobuf2_memops snd_hda_intel >> videobuf2_core rfcomm bnep snd_hda_controller option snd_hda_codec >> v4l2_common i915 joydev videodev usb_wwan snd_hwdep usbserial >> cdc_ether snd_pcm usbnet btusb snd_seq_midi snd_seq_midi_event >> bluetooth psmouse snd_rawmidi iwlwifi snd_seq i2c_algo_bit >> drm_kms_helper snd_timer serio_raw snd_seq_device samsung_laptop drm >> snd cfg80211 soundcore video lpc_ich intel_rst wmi mac_hid binfmt_misc >> lp parport hid_generic usbhid hid r8169 mii usb_storage >> [ 88.028694] CPU: 1 PID: 2539 Comm: fio Not tainted >> 3.19.0-rc2-next20141231-1-iniza-small #1 >> [ 88.028695] Hardware name: SAMSUNG ELECTRONICS CO., LTD. >> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 >> [ 88.028697] 81a66d5f 880070f43c38 8175c50c >> >> [ 88.028700] 880070f43c88 880070f43c78 810753ba >> 880070f43d28 >> [ 88.028703] 81a67ef5 026d >> 00dce810 >> [ 88.028706] Call Trace: >> [ 88.028712] [] dump_stack+0x4c/0x65 >> [ 88.028716] [] warn_slowpath_common+0x8a/0xc0 >> [ 88.028719] [] warn_slowpath_fmt+0x46/0x50 >> [ 88.028722] [] ? mark_held_locks+0x6d/0xa0 >> [ 88.028725] [] ? mutex_lock_nested+0x2b2/0x4e0 >> [ 88.028727] [] ? prepare_to_wait_event+0x5d/0x110 >> [ 88.028729] [] ? prepare_to_wait_event+0x5d/0x110 >> [ 88.028731] [] __might_sleep+0xbd/0xd0 >> [ 88.028734] [] mutex_lock_nested+0x2f/0x4e0 >> [ 88.028736] [] ? prepare_to_wait_event+0x53/0x110 >> [ 88.028739] [] aio_read_events+0x4f/0x2d0 >> [ 88.028742] [] ? trace_hardirqs_on+0xd/0x10 >> [ 88.028745] [] read_events+0x200/0x320 >> [ 88.028747] [] ? wait_woken+0xc0/0xc0 >> [ 88.028750] [] ? hrtimer_get_res+0x50/0x50 >> [ 88.028753] [] ? lookup_ioctx+0xd0/0x140 >> [ 88.028755] [] SyS_io_getevents+0x62/0x100 >> [ 88.028759] [] ? trace_hardirqs_on_thunk+0x3a/0x3f >> [ 88.028762] [] system_call_fastpath+0x16/0x1b >> [ 88.028764] ---[ end trace dba4f4a06fcdd178 ]--- It is an known linux-aio issue, see the following link: http://marc.info/?t=14192504964=1=2 Thanks, Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] btrfs: reada: Remove unused function
Remove the function btrfs_reada_detach() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
fs/btrfs/ctree.h |1 -
fs/btrfs/reada.c |9 +
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index fe69edd..030a7b5 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -4111,7 +4111,6 @@ struct reada_control {
struct reada_control *btrfs_reada_add(struct btrfs_root *root,
struct btrfs_key *start, struct btrfs_key *end);
int btrfs_reada_wait(void *handle);
-void btrfs_reada_detach(void *handle);
int btree_readahead_hook(struct btrfs_root *root, struct extent_buffer *eb,
u64 start, int err);
diff --git a/fs/btrfs/reada.c b/fs/btrfs/reada.c
index b63ae20..97073c0c 100644
--- a/fs/btrfs/reada.c
+++ b/fs/btrfs/reada.c
@@ -37,7 +37,7 @@
* To trigger a readahead, btrfs_reada_add must be called. It will start
* a read ahead for the given range [start, end) on tree root. The returned
* handle can either be used to wait on the readahead to finish
- * (btrfs_reada_wait), or to send it to the background (btrfs_reada_detach).
+ * (btrfs_reada_wait).
*
* The read ahead works as follows:
* On btrfs_reada_add, the root of the tree is inserted into a radix_tree.
@@ -986,10 +986,3 @@ int btrfs_reada_wait(void *handle)
return 0;
}
#endif
-
-void btrfs_reada_detach(void *handle)
-{
- struct reada_control *rc = handle;
-
- kref_put(>refcnt, reada_control_release);
-}
--
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/
[PATCH] brcm80211: brcmsmac: dma: Remove some unused functions
Removes some functions that are not used anywhere:
dma_txflush() dma_txsuspended()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/net/wireless/brcm80211/brcmsmac/dma.c | 19 ---
drivers/net/wireless/brcm80211/brcmsmac/dma.h |2 --
2 files changed, 21 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
index 796f5f9..bca233a 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
@@ -1192,16 +1192,6 @@ void dma_txresume(struct dma_pub *pub)
bcma_mask32(di->core, DMA64TXREGOFFS(di, control), ~D64_XC_SE);
}
-bool dma_txsuspended(struct dma_pub *pub)
-{
- struct dma_info *di = container_of(pub, struct dma_info, dma);
-
- return (di->ntxd == 0) ||
- ((bcma_read32(di->core,
-DMA64TXREGOFFS(di, control)) & D64_XC_SE) ==
- D64_XC_SE);
-}
-
void dma_txreclaim(struct dma_pub *pub, enum txd_range range)
{
struct dma_info *di = container_of(pub, struct dma_info, dma);
@@ -1425,15 +1415,6 @@ int dma_txfast(struct brcms_c_info *wlc, struct dma_pub
*pub,
return -ENOSPC;
}
-void dma_txflush(struct dma_pub *pub)
-{
- struct dma_info *di = container_of(pub, struct dma_info, dma);
- struct brcms_ampdu_session *session = >ampdu_session;
-
- if (!skb_queue_empty(>skb_list))
- ampdu_finalize(di);
-}
-
int dma_txpending(struct dma_pub *pub)
{
struct dma_info *di = container_of(pub, struct dma_info, dma);
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.h
b/drivers/net/wireless/brcm80211/brcmsmac/dma.h
index ff5b80b..210ec72 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/dma.h
+++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.h
@@ -88,11 +88,9 @@ bool dma_txreset(struct dma_pub *pub);
void dma_txinit(struct dma_pub *pub);
int dma_txfast(struct brcms_c_info *wlc, struct dma_pub *pub,
struct sk_buff *p0);
-void dma_txflush(struct dma_pub *pub);
int dma_txpending(struct dma_pub *pub);
void dma_kick_tx(struct dma_pub *pub);
void dma_txsuspend(struct dma_pub *pub);
-bool dma_txsuspended(struct dma_pub *pub);
void dma_txresume(struct dma_pub *pub);
void dma_txreclaim(struct dma_pub *pub, enum txd_range range);
void dma_rxreclaim(struct dma_pub *pub);
--
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: [LKP] [sched] a15b12ac36a: -46.9% time.voluntary_context_switches +1.5% will-it-scale.per_process_ops
Hi, Kirill,
Sorry for late.
On Tue, 2014-12-23 at 11:57 +0300, Kirill Tkhai wrote:
> Hi, Huang,
>
> what do these digits mean? What test does?
>
> 23.12.2014, 08:16, "Huang Ying" :
> > FYI, we noticed the below changes on
> >
> > commit a15b12ac36ad4e7b856a4ae54937ae26a51aebad ("sched: Do not stop cpu in
> > set_cpus_allowed_ptr() if task is not running")
> >
> > testbox/testcase/testparams: lkp-g5/will-it-scale/performance-lock1
> >
> > 1ba93d42727c4400 a15b12ac36ad4e7b856a4ae549
> > --
Above is the good commit and the bad commit.
> > %stddev %change %stddev
> > \ |\
> >1517261 ± 0% +1.5%1539994 ± 0% will-it-scale.per_process_ops
We have basic description of data above, where %stddev is standard
deviation.
What's more do you want?
Best Regards,
Huang, Ying
> >247 ± 30%+131.8%573 ± 49% sched_debug.cpu#61.ttwu_count
> >225 ± 22%+142.8%546 ± 34% sched_debug.cpu#81.ttwu_local
> > 15115 ± 44% +37.3% 20746 ± 40% numa-meminfo.node7.Active
> > 1028 ± 38%+115.3% 2214 ± 36% sched_debug.cpu#16.ttwu_local
> > 2 ± 19%+133.3% 5 ± 43% sched_debug.cpu#89.cpu_load[3]
> > 21 ± 45% +88.2% 40 ± 23%
> > sched_debug.cfs_rq[99]:/.tg_load_contrib
> >414 ± 33% +98.6%823 ± 28% sched_debug.cpu#81.ttwu_count
> > 4 ± 10% +88.2% 8 ± 12%
> > sched_debug.cfs_rq[33]:/.runnable_load_avg
> > 22 ± 26% +80.9% 40 ± 24%
> > sched_debug.cfs_rq[103]:/.tg_load_contrib
> > 7 ± 17% -41.4% 4 ± 25% sched_debug.cfs_rq[41]:/.load
> > 7 ± 17% -37.9% 4 ± 19% sched_debug.cpu#41.load
> > 3 ± 22%+106.7% 7 ± 10%
> > sched_debug.cfs_rq[36]:/.runnable_load_avg
> >174 ± 13% +48.7%259 ± 31% sched_debug.cpu#112.ttwu_count
> > 4 ± 19% +88.9% 8 ± 5%
> > sched_debug.cfs_rq[35]:/.runnable_load_avg
> >260 ± 10% +55.6%405 ± 26%
> > numa-vmstat.node3.nr_anon_pages
> > 1042 ± 10% +56.0% 1626 ± 26% numa-meminfo.node3.AnonPages
> > 26 ± 22% +74.3% 45 ± 16%
> > sched_debug.cfs_rq[65]:/.tg_load_contrib
> > 21 ± 43% +71.3% 37 ± 26%
> > sched_debug.cfs_rq[100]:/.tg_load_contrib
> > 3686 ± 21% +40.2% 5167 ± 19% sched_debug.cpu#16.ttwu_count
> >142 ± 9% +34.4%191 ± 24% sched_debug.cpu#112.ttwu_local
> > 5 ± 18% +69.6% 9 ± 15% sched_debug.cfs_rq[35]:/.load
> > 2 ± 30%+100.0% 5 ± 37%
> > sched_debug.cpu#106.cpu_load[1]
> > 3 ± 23%+100.0% 6 ± 48%
> > sched_debug.cpu#106.cpu_load[2]
> > 5 ± 18% +69.6% 9 ± 15% sched_debug.cpu#35.load
> > 9 ± 20% +48.6% 13 ± 16%
> > sched_debug.cfs_rq[7]:/.runnable_load_avg
> > 1727 ± 15% +43.9% 2484 ± 30% sched_debug.cpu#34.ttwu_local
> > 10 ± 17% -40.5% 6 ± 13% sched_debug.cpu#41.cpu_load[0]
> > 10 ± 14% -29.3% 7 ± 5% sched_debug.cpu#45.cpu_load[4]
> > 10 ± 17% -33.3% 7 ± 10% sched_debug.cpu#41.cpu_load[1]
> > 6121 ± 8% +56.7% 9595 ± 30%
> > sched_debug.cpu#13.sched_goidle
> > 13 ± 8% -25.9% 10 ± 17% sched_debug.cpu#39.cpu_load[2]
> > 12 ± 16% -24.0% 9 ± 15% sched_debug.cpu#37.cpu_load[2]
> >492 ± 17% -21.3%387 ± 24% sched_debug.cpu#46.ttwu_count
> > 3761 ± 11% -23.9% 2863 ± 15% sched_debug.cpu#93.curr->pid
> >570 ± 19% +43.2%816 ± 17% sched_debug.cpu#86.ttwu_count
> > 5279 ± 8% +63.5% 8631 ± 33% sched_debug.cpu#13.ttwu_count
> >377 ± 22% -28.6%269 ± 14% sched_debug.cpu#46.ttwu_local
> > 5396 ± 10% +29.9% 7007 ± 14%
> > sched_debug.cpu#16.sched_goidle
> > 1959 ± 12% +36.9% 2683 ± 15%
> > numa-vmstat.node2.nr_slab_reclaimable
> > 7839 ± 12% +37.0% 10736 ± 15%
> > numa-meminfo.node2.SReclaimable
> > 5 ± 15% +66.7% 8 ± 9% sched_debug.cfs_rq[33]:/.load
> > 5 ± 25% +47.8% 8 ± 10% sched_debug.cfs_rq[37]:/.load
> > 2 ± 0% +87.5% 3 ± 34% sched_debug.cpu#89.cpu_load[4]
> > 5 ± 15% +66.7% 8 ± 9% sched_debug.cpu#33.load
> > 6 ± 23% +41.7% 8 ± 10% sched_debug.cpu#37.load
> > 8 ± 10% -26.5% 6 ± 6% sched_debug.cpu#51.cpu_load[1]
> > 7300 ± 37% +63.6% 11943 ± 16% softirqs.TASKLET
> > 2984 ± 6% +43.1% 4271 ± 23% sched_debug.cpu#20.ttwu_count
> >328 ± 4% +40.5%462 ± 25% sched_debug.cpu#26.ttwu_local
> > 10 ± 7%
[PATCH] soc: intel: sst-haswell-ipc: Remove some unused functions
Removes some functions that are not used anywhere:
sst_hsw_stream_unmute() sst_hsw_stream_mute() msg_set_stage_type()
sst_hsw_dx_get_state() sst_hsw_dx_set_state()
sst_hsw_stream_set_write_position()
sst_hsw_stream_get_vol_reg() sst_hsw_stream_get_peak_reg()
sst_hsw_stream_get_pointer_reg() sst_hsw_stream_get_read_reg()
sst_hsw_stream_get_mixer_id() sst_hsw_stream_get_hw_id()
sst_hsw_mixer_set_volume_curve() sst_hsw_mixer_unmute() sst_hsw_mixer_mute()
sst_hsw_stream_set_volume_curve()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
sound/soc/intel/sst-haswell-ipc.c | 226 -
sound/soc/intel/sst-haswell-ipc.h | 34 --
2 files changed, 260 deletions(-)
diff --git a/sound/soc/intel/sst-haswell-ipc.c
b/sound/soc/intel/sst-haswell-ipc.c
index b629151..26f856c 100644
--- a/sound/soc/intel/sst-haswell-ipc.c
+++ b/sound/soc/intel/sst-haswell-ipc.c
@@ -333,12 +333,6 @@ static inline u32 msg_get_stage_type(u32 msg)
return (msg & IPC_STG_TYPE_MASK) >> IPC_STG_TYPE_SHIFT;
}
-static inline u32 msg_set_stage_type(u32 msg, u32 type)
-{
- return (msg & ~IPC_STG_TYPE_MASK) +
- (type << IPC_STG_TYPE_SHIFT);
-}
-
static inline u32 msg_get_stream_id(u32 msg)
{
return (msg & IPC_STR_ID_MASK) >> IPC_STR_ID_SHIFT;
@@ -965,45 +959,6 @@ int sst_hsw_fw_get_version(struct sst_hsw *hsw,
}
/* Mixer Controls */
-int sst_hsw_stream_mute(struct sst_hsw *hsw, struct sst_hsw_stream *stream,
- u32 stage_id, u32 channel)
-{
- int ret;
-
- ret = sst_hsw_stream_get_volume(hsw, stream, stage_id, channel,
- >mute_volume[channel]);
- if (ret < 0)
- return ret;
-
- ret = sst_hsw_stream_set_volume(hsw, stream, stage_id, channel, 0);
- if (ret < 0) {
- dev_err(hsw->dev, "error: can't unmute stream %d channel %d\n",
- stream->reply.stream_hw_id, channel);
- return ret;
- }
-
- stream->mute[channel] = 1;
- return 0;
-}
-
-int sst_hsw_stream_unmute(struct sst_hsw *hsw, struct sst_hsw_stream *stream,
- u32 stage_id, u32 channel)
-
-{
- int ret;
-
- stream->mute[channel] = 0;
- ret = sst_hsw_stream_set_volume(hsw, stream, stage_id, channel,
- stream->mute_volume[channel]);
- if (ret < 0) {
- dev_err(hsw->dev, "error: can't unmute stream %d channel %d\n",
- stream->reply.stream_hw_id, channel);
- return ret;
- }
-
- return 0;
-}
-
int sst_hsw_stream_get_volume(struct sst_hsw *hsw, struct sst_hsw_stream
*stream,
u32 stage_id, u32 channel, u32 *volume)
{
@@ -1017,17 +972,6 @@ int sst_hsw_stream_get_volume(struct sst_hsw *hsw, struct
sst_hsw_stream *stream
return 0;
}
-int sst_hsw_stream_set_volume_curve(struct sst_hsw *hsw,
- struct sst_hsw_stream *stream, u64 curve_duration,
- enum sst_hsw_volume_curve curve)
-{
- /* curve duration in steps of 100ns */
- stream->vol_req.curve_duration = curve_duration;
- stream->vol_req.curve_type = curve;
-
- return 0;
-}
-
/* stream volume */
int sst_hsw_stream_set_volume(struct sst_hsw *hsw,
struct sst_hsw_stream *stream, u32 stage_id, u32 channel, u32 volume)
@@ -1065,42 +1009,6 @@ int sst_hsw_stream_set_volume(struct sst_hsw *hsw,
return 0;
}
-int sst_hsw_mixer_mute(struct sst_hsw *hsw, u32 stage_id, u32 channel)
-{
- int ret;
-
- ret = sst_hsw_mixer_get_volume(hsw, stage_id, channel,
- >mute_volume[channel]);
- if (ret < 0)
- return ret;
-
- ret = sst_hsw_mixer_set_volume(hsw, stage_id, channel, 0);
- if (ret < 0) {
- dev_err(hsw->dev, "error: failed to unmute mixer channel %d\n",
- channel);
- return ret;
- }
-
- hsw->mute[channel] = 1;
- return 0;
-}
-
-int sst_hsw_mixer_unmute(struct sst_hsw *hsw, u32 stage_id, u32 channel)
-{
- int ret;
-
- ret = sst_hsw_mixer_set_volume(hsw, stage_id, channel,
- hsw->mixer_info.volume_register_address[channel]);
- if (ret < 0) {
- dev_err(hsw->dev, "error: failed to unmute mixer channel %d\n",
- channel);
- return ret;
- }
-
- hsw->mute[channel] = 0;
- return 0;
-}
-
int sst_hsw_mixer_get_volume(struct sst_hsw *hsw, u32 stage_id, u32 channel,
u32 *volume)
{
@@ -1114,16 +1022,6 @@ int sst_hsw_mixer_get_volume(struct sst_hsw *hsw, u32
stage_id, u32 channel,
return 0;
}
-int sst_hsw_mixer_set_volume_curve(struct sst_hsw *hsw,
-u64 curve_duration, enum sst_hsw_volume_curve curve)
-{
- /* curve duration in steps of 100ns */
- hsw->curve_duration = curve_duration;
- hsw->curve_type = curve;
-
- return 0;
-}
-
/* global mixer
[PATCH] mfd: omap-usb-host: Remove some unused functions
Removes some functions that are not used anywhere:
usbhs_readb() usbhs_writeb()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/mfd/omap-usb-host.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 83dab2f..6b0f305 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -129,16 +129,6 @@ static inline u32 usbhs_read(void __iomem *base, u32 reg)
return readl_relaxed(base + reg);
}
-static inline void usbhs_writeb(void __iomem *base, u8 reg, u8 val)
-{
- writeb_relaxed(val, base + reg);
-}
-
-static inline u8 usbhs_readb(void __iomem *base, u8 reg)
-{
- return readb_relaxed(base + reg);
-}
-
/*-*/
/**
--
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: [next-20141231] sched: WARNING: CPU: 1 PID: 2539 at kernel/sched/core.c:7303 __might_sleep+0xbd/0xd0()
On Thu, Jan 1, 2015 at 11:28 AM, Sedat Dilek wrote: > Hi, > > with next-20141231 I am seeing this call-trace: > > [ 88.028632] [ cut here ] > [ 88.028643] WARNING: CPU: 1 PID: 2539 at kernel/sched/core.c:7303 > __might_sleep+0xbd/0xd0() > [ 88.028646] do not call blocking ops when !TASK_RUNNING; state=1 > set at [] prepare_to_wait_event+0x5d/0x110 > [ 88.028648] Modules linked in: ppp_deflate bsd_comp ppp_async > crc_ccitt arc4 iwldvm uvcvideo mac80211 snd_hda_codec_hdmi > snd_hda_codec_realtek parport_pc videobuf2_vmalloc > snd_hda_codec_generic ppdev videobuf2_memops snd_hda_intel > videobuf2_core rfcomm bnep snd_hda_controller option snd_hda_codec > v4l2_common i915 joydev videodev usb_wwan snd_hwdep usbserial > cdc_ether snd_pcm usbnet btusb snd_seq_midi snd_seq_midi_event > bluetooth psmouse snd_rawmidi iwlwifi snd_seq i2c_algo_bit > drm_kms_helper snd_timer serio_raw snd_seq_device samsung_laptop drm > snd cfg80211 soundcore video lpc_ich intel_rst wmi mac_hid binfmt_misc > lp parport hid_generic usbhid hid r8169 mii usb_storage > [ 88.028694] CPU: 1 PID: 2539 Comm: fio Not tainted > 3.19.0-rc2-next20141231-1-iniza-small #1 > [ 88.028695] Hardware name: SAMSUNG ELECTRONICS CO., LTD. > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 > [ 88.028697] 81a66d5f 880070f43c38 8175c50c > > [ 88.028700] 880070f43c88 880070f43c78 810753ba > 880070f43d28 > [ 88.028703] 81a67ef5 026d > 00dce810 > [ 88.028706] Call Trace: > [ 88.028712] [] dump_stack+0x4c/0x65 > [ 88.028716] [] warn_slowpath_common+0x8a/0xc0 > [ 88.028719] [] warn_slowpath_fmt+0x46/0x50 > [ 88.028722] [] ? mark_held_locks+0x6d/0xa0 > [ 88.028725] [] ? mutex_lock_nested+0x2b2/0x4e0 > [ 88.028727] [] ? prepare_to_wait_event+0x5d/0x110 > [ 88.028729] [] ? prepare_to_wait_event+0x5d/0x110 > [ 88.028731] [] __might_sleep+0xbd/0xd0 > [ 88.028734] [] mutex_lock_nested+0x2f/0x4e0 > [ 88.028736] [] ? prepare_to_wait_event+0x53/0x110 > [ 88.028739] [] aio_read_events+0x4f/0x2d0 > [ 88.028742] [] ? trace_hardirqs_on+0xd/0x10 > [ 88.028745] [] read_events+0x200/0x320 > [ 88.028747] [] ? wait_woken+0xc0/0xc0 > [ 88.028750] [] ? hrtimer_get_res+0x50/0x50 > [ 88.028753] [] ? lookup_ioctx+0xd0/0x140 > [ 88.028755] [] SyS_io_getevents+0x62/0x100 > [ 88.028759] [] ? trace_hardirqs_on_thunk+0x3a/0x3f > [ 88.028762] [] system_call_fastpath+0x16/0x1b > [ 88.028764] ---[ end trace dba4f4a06fcdd178 ]--- > > Attached are my kernel-config, kern-log and patch. > > Please, contact me if you need more informations. > [ CC Jens and Ming Lei ] This is reprocible when running fio for example. # grep "Comm: fio" /var/log/kern.log | grep next Dec 31 22:16:11 fambox kernel: [ 4164.195498] CPU: 0 PID: 31786 Comm: fio Not tainted 3.19.0-rc2-next20141231-2-iniza-small #1 Dec 31 22:32:28 fambox kernel: [ 88.028694] CPU: 1 PID: 2539 Comm: fio Not tainted 3.19.0-rc2-next20141231-1-iniza-small #1 Jan 1 14:57:24 fambox kernel: [ 152.560454] CPU: 3 PID: 2647 Comm: fio Not tainted 3.19.0-rc2-next20141231-1-loopmq-small #1 Jan 1 15:41:36 fambox kernel: [ 132.919590] CPU: 0 PID: 2667 Comm: fio Not tainted 3.19.0-rc2-next20141231-3-loopmq-small #1 Jan 1 21:45:48 fambox kernel: [ 603.958985] CPU: 3 PID: 2868 Comm: fio Not tainted 3.19.0-rc2-next20141231-4-loopmq-small #1 Jan 2 00:13:58 fambox kernel: [ 306.024050] CPU: 1 PID: 2977 Comm: fio Not tainted 3.19.0-rc2-next20141231.4-loopmq-small #1 Jan 2 05:37:00 fambox kernel: [ 372.874364] CPU: 2 PID: 3088 Comm: fio Not tainted 3.19.0-rc2-next-20141231.5-loopmq-small #1 Jan 3 14:43:09 fambox kernel: [ 557.742941] CPU: 0 PID: 7003 Comm: fio-2.2.3 Not tainted 3.19.0-rc2-next-20141231.6-loopmq-small #1 Jan 3 19:37:27 fambox kernel: [ 1428.960438] CPU: 1 PID: 4936 Comm: fio-2.2.3 Not tainted 3.19.0-rc2-next-20141231.6-loopmq-small #1 Jan 4 00:34:06 fambox kernel: [15101.094582] CPU: 0 PID: 12394 Comm: fio-2.2.3 Not tainted 3.19.0-rc2-next-20141231.6-loopmq-small #1 - Sedat - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ceph: acl: Remove unused function
Remove the function ceph_get_cached_acl() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
fs/ceph/acl.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/fs/ceph/acl.c b/fs/ceph/acl.c
index 5bd853b..64fa248 100644
--- a/fs/ceph/acl.c
+++ b/fs/ceph/acl.c
@@ -40,20 +40,6 @@ static inline void ceph_set_cached_acl(struct inode *inode,
spin_unlock(>i_ceph_lock);
}
-static inline struct posix_acl *ceph_get_cached_acl(struct inode *inode,
- int type)
-{
- struct ceph_inode_info *ci = ceph_inode(inode);
- struct posix_acl *acl = ACL_NOT_CACHED;
-
- spin_lock(>i_ceph_lock);
- if (__ceph_caps_issued_mask(ci, CEPH_CAP_XATTR_SHARED, 0))
- acl = get_cached_acl(inode, type);
- spin_unlock(>i_ceph_lock);
-
- return acl;
-}
-
struct posix_acl *ceph_get_acl(struct inode *inode, int type)
{
int size;
--
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 V3] ARM: dts: am57xx-beagle-x15: Add GPIO controlled fan node
Hi Nishanth, On Sat, Jan 03, 2015 at 12:30:26PM -0600, Nishanth Menon wrote: > [...] > + gpio-fan,speed-map = <00 > + 13000 1>; > [...] iirc DT maintainers prefer this format: gpio-fan,speed-map = <0 0>, <13000 1>; This should result in the same .dtb, but is a bit easier to read. -- Sebastian signature.asc Description: Digital signature
[PATCH] drm/radeon: do not left queue acquired if timeout happens in kgd_hqd_destroy()
If timeout happens, kgd_hqd_destroy() just returns -ETIME leaving queue
acquired.
It may cause a deadlock, so the patch proposes to release queue before return.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/gpu/drm/radeon/radeon_kfd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c
b/drivers/gpu/drm/radeon/radeon_kfd.c
index 242fd8b1b221..335e29dbab05 100644
--- a/drivers/gpu/drm/radeon/radeon_kfd.c
+++ b/drivers/gpu/drm/radeon/radeon_kfd.c
@@ -556,6 +556,7 @@ static int kgd_hqd_destroy(struct kgd_dev *kgd, uint32_t
reset_type,
if (timeout == 0) {
pr_err("kfd: cp queue preemption time out (%dms)\n",
temp);
+ release_queue(kgd);
return -ETIME;
}
msleep(20);
--
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] x86, um: actually mark system call tables readonly
On 01/03/2015 10:40 PM, Richard Weinberger wrote: ... I'll pick up this patch. Thanks a lot, Richard! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Deter exploit bruteforcing
Am 04.01.2015 um 00:06 schrieb Andy Lutomirski: > As an attempt to help end this particular line of debate: putting the > sleep in glibc won't work. The point isn't to make the crashed > process crash more slowly; it's to limit the rate at which *new* > siblings can be forked and crashed as a canary or ASLR brute-force > probe. IOW, adding a sleep call to glibc slows down the wrong thing. > Also, trying to get libc to take action on a plain old segfault is a > giant mess, because it involves mucking with signal handling, which > glibc really has no business doing by default. Thanks for pointing this out! > Also, this patch is missing a bit, I think. We really want to control > the total rate of crashes. This patch imposes a delay per crash, but > AFAICS it would still be possible for an attacker to coerce a forking > server to fork, say, 10k children, then probe all of them, then wait > 30 seconds and repeat. Sounds reasonable. This is exactly why I've extracted that feature from grsecurity and posted it here on LKML. Now we have the chance to make the feature better and can identify weak points. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Deter exploit bruteforcing
Am 04.01.2015 um 00:01 schrieb Pavel Machek: > On Sat 2015-01-03 23:44:18, Richard Weinberger wrote: >> Am 03.01.2015 um 23:36 schrieb Pavel Machek: >>> >> No. This is not what this patch does. >> >>> But changing glibc to do sleep(30); abort(); instead of abort(); to >>> slow down bruteforcing of canaries makes some kind of sense... and >>> should be ok by default. >> >> As I saidn only focusing one the specific stack canary case is not >> enough. > > Ok, so I am now saying "adding random delays to the kernel, hoping > they slow attacker down" is bad idea. Feel free to add my NAK to the > patch. The patch does not add random delays nor is hope involved. It has a very clear purpose, it makes brute force attacks to forking services unattractive. Exploits often use the fact that after fork() the child has the same memory as the parent and therefore an attacker can start fruitful brute force attacks to brute stack canaries, offsets, etc. as the new child will always have mostly the same memory layout as before. But I'll happily add your NAK to this series. >>> >>> Please do. >>> > If really neccessary, "kill_me_slowly()" syscall would be acceptable, > but it seems just sleep(); abort(); combination is enough. The goal of the patch is not to protect only against brute forcing the stack canary. It should protect against all kind of brute forcing using forking services. > glibc should cover 99% cases where this matters, please just fix glibc, > others will follow. There are a lot of systems out there without glibc. >>> >>> Only "interesting" systems that are without glibc are androids, and >>> they usually run very old kernels. >>> >>> If you implement sleep() in glibc, distros will enable it and you'll >>> protect all the desktop users. >>> >>> If you implement it in kernel, it will not be compatible-enough to be >>> enabled by default, and you'll be protecting special "high security" >>> distros at most. >>> And many applications make system calls without going though any libc wrapper. Hey, we want also protect esoteric distros like http://sta.li. :-) >>> >>> No, we don't. We want to maximize number of protected users. And >>> patching glibc does that. (And then you can patch bionic. And then the >>> small players will follow). >> >> And what about static linked programs or programs which do not use a libc >> wrapper >> for system calls? >> Say, any program written in go? > > And what about my Atari 800XL? If it runs Linux it can be protected. > How many such programs are on common distributions? <1% > > How many systems will your kernel hack leave unprotected? >70% > > (Plus, reasonable languages like go should not really allow classical > buffer overflows, and yes, you'll get protection if you statically > link against glibc. And AFAICT this has nothing to do with syscalls, > and everything to do with abort() implementation.). Go does not use libc at all. Anyway, you've stated your point. I'm for a generic solution and not for one which works only for some systems. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Deter exploit bruteforcing
On Sat, Jan 3, 2015 at 2:36 PM, Pavel Machek wrote: > >> >> No. This is not what this patch does. >> >> >> >>> But changing glibc to do sleep(30); abort(); instead of abort(); to >> >>> slow down bruteforcing of canaries makes some kind of sense... and >> >>> should be ok by default. >> >> >> >> As I saidn only focusing one the specific stack canary case is not enough. >> > >> > Ok, so I am now saying "adding random delays to the kernel, hoping >> > they slow attacker down" is bad idea. Feel free to add my NAK to the >> > patch. >> >> The patch does not add random delays nor is hope involved. >> >> It has a very clear purpose, it makes brute force attacks to forking >> services unattractive. >> Exploits often use the fact that after fork() the child has the same memory >> as the parent and therefore an attacker can start fruitful brute force >> attacks >> to brute stack canaries, offsets, etc. as the new child will always have >> mostly >> the same memory layout as before. >> >> But I'll happily add your NAK to this series. > > Please do. > >> > If really neccessary, "kill_me_slowly()" syscall would be acceptable, >> > but it seems just sleep(); abort(); combination is enough. >> >> The goal of the patch is not to protect only against brute forcing the stack >> canary. >> It should protect against all kind of brute forcing using forking services. >> >> > glibc should cover 99% cases where this matters, please just fix glibc, >> > others will follow. >> >> There are a lot of systems out there without glibc. > > Only "interesting" systems that are without glibc are androids, and > they usually run very old kernels. > > If you implement sleep() in glibc, distros will enable it and you'll > protect all the desktop users. As an attempt to help end this particular line of debate: putting the sleep in glibc won't work. The point isn't to make the crashed process crash more slowly; it's to limit the rate at which *new* siblings can be forked and crashed as a canary or ASLR brute-force probe. IOW, adding a sleep call to glibc slows down the wrong thing. Also, trying to get libc to take action on a plain old segfault is a giant mess, because it involves mucking with signal handling, which glibc really has no business doing by default. Also, this patch is missing a bit, I think. We really want to control the total rate of crashes. This patch imposes a delay per crash, but AFAICS it would still be possible for an attacker to coerce a forking server to fork, say, 10k children, then probe all of them, then wait 30 seconds and repeat. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] Deter exploit bruteforcing
On Sat 2015-01-03 23:44:18, Richard Weinberger wrote: > Am 03.01.2015 um 23:36 schrieb Pavel Machek: > > > No. This is not what this patch does. > > > But changing glibc to do sleep(30); abort(); instead of abort(); to > > slow down bruteforcing of canaries makes some kind of sense... and > > should be ok by default. > > As I saidn only focusing one the specific stack canary case is not > enough. > >>> > >>> Ok, so I am now saying "adding random delays to the kernel, hoping > >>> they slow attacker down" is bad idea. Feel free to add my NAK to the > >>> patch. > >> > >> The patch does not add random delays nor is hope involved. > >> > >> It has a very clear purpose, it makes brute force attacks to forking > >> services unattractive. > >> Exploits often use the fact that after fork() the child has the same memory > >> as the parent and therefore an attacker can start fruitful brute force > >> attacks > >> to brute stack canaries, offsets, etc. as the new child will always have > >> mostly > >> the same memory layout as before. > >> > >> But I'll happily add your NAK to this series. > > > > Please do. > > > >>> If really neccessary, "kill_me_slowly()" syscall would be acceptable, > >>> but it seems just sleep(); abort(); combination is enough. > >> > >> The goal of the patch is not to protect only against brute forcing the > >> stack canary. > >> It should protect against all kind of brute forcing using forking services. > >> > >>> glibc should cover 99% cases where this matters, please just fix glibc, > >>> others will follow. > >> > >> There are a lot of systems out there without glibc. > > > > Only "interesting" systems that are without glibc are androids, and > > they usually run very old kernels. > > > > If you implement sleep() in glibc, distros will enable it and you'll > > protect all the desktop users. > > > > If you implement it in kernel, it will not be compatible-enough to be > > enabled by default, and you'll be protecting special "high security" > > distros at most. > > > >> And many applications make system calls without going though any libc > >> wrapper. > >> Hey, we want also protect esoteric distros like http://sta.li. :-) > > > > No, we don't. We want to maximize number of protected users. And > > patching glibc does that. (And then you can patch bionic. And then the > > small players will follow). > > And what about static linked programs or programs which do not use a libc > wrapper > for system calls? > Say, any program written in go? And what about my Atari 800XL? How many such programs are on common distributions? <1% How many systems will your kernel hack leave unprotected? >70% (Plus, reasonable languages like go should not really allow classical buffer overflows, and yes, you'll get protection if you statically link against glibc. And AFAICT this has nothing to do with syscalls, and everything to do with abort() implementation.). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 0/5] *** SUBJECT HERE ***
On Sat, 2015-01-03 at 08:45 -0800, Greg KH wrote: > On Sat, Jan 03, 2015 at 02:06:22PM +0530, jitendra kumar khasdev wrote: > > *** BLURB HERE *** > > What blurb? What subject? jitendra used git-send-email to send this series. You'd expect git-send-email to die with an error if the cover letter, which it should see first, still contains these "*** [...] HERE ***" markers. What's the reason it doesn't do that? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Deter exploit bruteforcing
Am 03.01.2015 um 23:36 schrieb Pavel Machek: > No. This is not what this patch does. > But changing glibc to do sleep(30); abort(); instead of abort(); to > slow down bruteforcing of canaries makes some kind of sense... and > should be ok by default. As I saidn only focusing one the specific stack canary case is not enough. >>> >>> Ok, so I am now saying "adding random delays to the kernel, hoping >>> they slow attacker down" is bad idea. Feel free to add my NAK to the >>> patch. >> >> The patch does not add random delays nor is hope involved. >> >> It has a very clear purpose, it makes brute force attacks to forking >> services unattractive. >> Exploits often use the fact that after fork() the child has the same memory >> as the parent and therefore an attacker can start fruitful brute force >> attacks >> to brute stack canaries, offsets, etc. as the new child will always have >> mostly >> the same memory layout as before. >> >> But I'll happily add your NAK to this series. > > Please do. > >>> If really neccessary, "kill_me_slowly()" syscall would be acceptable, >>> but it seems just sleep(); abort(); combination is enough. >> >> The goal of the patch is not to protect only against brute forcing the stack >> canary. >> It should protect against all kind of brute forcing using forking services. >> >>> glibc should cover 99% cases where this matters, please just fix glibc, >>> others will follow. >> >> There are a lot of systems out there without glibc. > > Only "interesting" systems that are without glibc are androids, and > they usually run very old kernels. > > If you implement sleep() in glibc, distros will enable it and you'll > protect all the desktop users. > > If you implement it in kernel, it will not be compatible-enough to be > enabled by default, and you'll be protecting special "high security" > distros at most. > >> And many applications make system calls without going though any libc >> wrapper. >> Hey, we want also protect esoteric distros like http://sta.li. :-) > > No, we don't. We want to maximize number of protected users. And > patching glibc does that. (And then you can patch bionic. And then the > small players will follow). And what about static linked programs or programs which do not use a libc wrapper for system calls? Say, any program written in go? Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Deter exploit bruteforcing
> >> No. This is not what this patch does. > >> > >>> But changing glibc to do sleep(30); abort(); instead of abort(); to > >>> slow down bruteforcing of canaries makes some kind of sense... and > >>> should be ok by default. > >> > >> As I saidn only focusing one the specific stack canary case is not enough. > > > > Ok, so I am now saying "adding random delays to the kernel, hoping > > they slow attacker down" is bad idea. Feel free to add my NAK to the > > patch. > > The patch does not add random delays nor is hope involved. > > It has a very clear purpose, it makes brute force attacks to forking > services unattractive. > Exploits often use the fact that after fork() the child has the same memory > as the parent and therefore an attacker can start fruitful brute force attacks > to brute stack canaries, offsets, etc. as the new child will always have > mostly > the same memory layout as before. > > But I'll happily add your NAK to this series. Please do. > > If really neccessary, "kill_me_slowly()" syscall would be acceptable, > > but it seems just sleep(); abort(); combination is enough. > > The goal of the patch is not to protect only against brute forcing the stack > canary. > It should protect against all kind of brute forcing using forking services. > > > glibc should cover 99% cases where this matters, please just fix glibc, > > others will follow. > > There are a lot of systems out there without glibc. Only "interesting" systems that are without glibc are androids, and they usually run very old kernels. If you implement sleep() in glibc, distros will enable it and you'll protect all the desktop users. If you implement it in kernel, it will not be compatible-enough to be enabled by default, and you'll be protecting special "high security" distros at most. > And many applications make system calls without going though any libc wrapper. > Hey, we want also protect esoteric distros like http://sta.li. :-) No, we don't. We want to maximize number of protected users. And patching glibc does that. (And then you can patch bionic. And then the small players will follow). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
[PATCH v2] mfd: lubbock_io: add lubbock_io board
Lubbock () board is the IO motherboard of the Intel PXA25x Development
Platform, which supports the Lubbock pxa25x soc board.
Historically, this support was in arch/arm/mach-pxa/lubbock.c. When
gpio-pxa was moved to drivers/pxa, it became a driver, and its
initialization and probing happened at postcore initcall. The lubbock
code used to install the chained lubbock interrupt handler at init_irq()
time.
The consequence of the gpio-pxa change is that the installed chained irq
handler lubbock_irq_handler() was overwritten in pxa_gpio_probe(_dt)(),
removing :
- the handler
- the falling edge detection setting of GPIO0, which revealed the
interrupt request from the lubbock IO board.
As a fix, move the gpio0 chained handler setup to a place where we have
the guarantee that pxa_gpio_probe() was called before, so that lubbock
handler becomes the true IRQ chained handler of GPIO0, demuxing the
lubbock IO board interrupts.
This patch moves all that handling to a mfd driver. It's only purpose
for the time being is the interrupt handling, but in the future it
should encompass all the motherboard CPLDs handling :
- leds
- switches
- hexleds
Signed-off-by: Robert Jarzmik
---
Since v1: change the name from cottula to lubbock_io
Dmitry pointed out the Cottula was the pxa25x family name,
lubbock was the pxa25x development board name. Therefore the
name was changed to lubbock_io (lubbock IO board)
change the resources to bi-irq ioresource
Discussion between Arnd and Robert to change the gpio
request by a irq request.
---
drivers/mfd/Kconfig | 10 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/lubbock.c | 193 ++
3 files changed, 204 insertions(+)
create mode 100644 drivers/mfd/lubbock.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2e6b731..4d8939f 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -91,6 +91,16 @@ config MFD_AXP20X
components like regulators or the PEK (Power Enable Key) under the
corresponding menus.
+config MFD_LUBBOCK
+ bool "Lubbock Motherboard"
+ def_bool ARCH_LUBBOCK
+ select MFD_CORE
+ help
+ This driver supports the Lubbock multifunction chip found on the
+ pxa25x development platform system (named Lubbock). This IO board
+ supports the interrupts handling, ethernet controller, flash chips,
+ etc ...
+
config MFD_CROS_EC
tristate "ChromeOS Embedded Controller"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..aff1f4f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
obj-$(CONFIG_MFD_SM501)+= sm501.o
obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o
+obj-$(CONFIG_MFD_LUBBOCK) += lubbock.o
obj-$(CONFIG_MFD_CROS_EC) += cros_ec.o
obj-$(CONFIG_MFD_CROS_EC_I2C) += cros_ec_i2c.o
obj-$(CONFIG_MFD_CROS_EC_SPI) += cros_ec_spi.o
diff --git a/drivers/mfd/lubbock.c b/drivers/mfd/lubbock.c
new file mode 100644
index 000..c6ce82c
--- /dev/null
+++ b/drivers/mfd/lubbock.c
@@ -0,0 +1,193 @@
+/*
+ * Intel Cotulla MFD - lubbock motherboard
+ *
+ * Copyright (C) 2014 Robert Jarzmik
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Lubbock motherboard driver, supporting lubbock (aka. pxa25x) soc board.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define COT_IRQ_MASK_EN 0xc0
+#define COT_IRQ_SET_CLR 0xd0
+
+#define LUBBOCK_NB_IRQ 8
+
+struct lubbock {
+ void __iomem*base;
+ int irq;
+ unsigned int irq_mask;
+ struct gpio_desc *gpio0;
+ struct irq_domain *irqdomain;
+};
+
+static irqreturn_t lubbock_irq_handler(int in_irq, void *d)
+{
+ struct lubbock *cot = d;
+ unsigned long pending;
+ unsigned int bit;
+
+ pending = readl(cot->base + COT_IRQ_SET_CLR) & cot->irq_mask;
+ for_each_set_bit(bit, , LUBBOCK_NB_IRQ)
+ generic_handle_irq(irq_find_mapping(cot->irqdomain, bit));
+ return IRQ_HANDLED;
+}
+
+static void lubbock_irq_mask_ack(struct irq_data *d)
+{
+ struct lubbock *cot = irq_data_get_irq_chip_data(d);
+ unsigned int lubbock_irq = irqd_to_hwirq(d);
+ unsigned int set, bit = BIT(lubbock_irq);
+
+ cot->irq_mask &= ~bit;
+ writel(cot->irq_mask, cot->base + COT_IRQ_MASK_EN);
+ set = readl(cot->base + COT_IRQ_SET_CLR);
+ writel(set & ~bit, cot->base + COT_IRQ_SET_CLR);
+}
+
+static void lubbock_irq_unmask(struct irq_data *d)
+{
+
Re: [PATCH] Revert "ipw2200: select CFG80211_WEXT"
On Sat, 2015-01-03 at 10:07 -0800, Linus Torvalds wrote: > On Sat, Jan 3, 2015 at 10:02 AM, Marcel Holtmann wrote: > > > > why would you revert this? It is obviously the correct change to actually > > select CFG80211_WEXT. > > I don't know about obvious, but yeah, I think the select in this case > is actually the better idea anyway. Obviously it wasn't obvious to me! My reasoning was that the "ipw2200: select CFG80211_WEXT" commit was _solely_ a workaround for the breakage introduced by that other patch. And since that one is now reverted the workaround wasn't needed anymore. Besied, I thought we try to avoid select-ing symbols that can also be set manually. As that makes it more likely to trigger circular dependency problems in the kconfig tools, doesn't it? > We could make the CFG80211_WEXT help message be very negative so that > people aren't encouraged to select it even if they can, but then if > they need the ipw driver it gets selected because of that. Because the > ipw driver is probably the more important of the two if you just > happen to have old hardware but are upgrading yout software (and > anybody who recompiles their own kernel is obviously doing the > latter). Side note: am I correct in thinking that there's some successor to CFG80211_WEXT and that the ipw2200 driver could, at least in theory, be ported to that successor? (ipw2200 hardware appears to be a bit old, so probably no one would care enough to actually do that.) net/wireless/kconfig doesn't mention anything like that, so probably I'm just confused. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/6] support GMAC driver for RK3288
Am Donnerstag, 1. Januar 2015, 21:01:22 schrieb David Miller: > From: Heiko Stübner > Date: Thu, 01 Jan 2015 03:06:31 +0100 > > > Hi David, > > > > Am Mittwoch, 31. Dezember 2014, 19:15:38 schrieb David Miller: > >> From: Roger Chen > >> Date: Mon, 29 Dec 2014 17:42:32 +0800 > >> > >> > Roger Chen (6): > >> > patch1: add driver for Rockchip RK3288 SoCs integrated GMAC > >> > patch2: define clock ID used for GMAC > >> > patch3: modify CRU config for Rockchip RK3288 SoCs integrated GMAC > >> > patch4: dts: rockchip: add gmac info for rk3288 > >> > patch5: dts: rockchip: enable gmac on RK3288 evb board > >> > patch6: add document for Rockchip RK3288 GMAC > >> > > >> > Tested on rk3288 evb board: > >> > Execute the following command to enable ethernet, > >> > set local IP and ping a remote host. > >> > > >> > busybox ifconfig eth0 up > >> > busybox ifconfig eth0 192.168.1.111 > >> > ping 192.168.1.1 > >> > >> Series applied to net-next, thanks. > > > > could we split this up a bit instead? > > Too late, what's in my tree is in the permanent commit history > and cannot be deleted. ok no problem ... I'll work around it then so that any possible conflicts are easily solvable. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] thermal: add omap3 support
Hi!
> Thanks for sending your code.
You are welcome.
> > Add support for omap3430 sensor. Tested on Nokia N900.
>
> To my understanding, and as already mentioned by Nishanth Menon
> (currently TIer), TI has intentionally avoided adding this support.
Well, Nokia had similar code in their kernel.
> There is a hardware accuracy limitation in this sensor, and therefore it
> is not advisable to use it, specially in Dynamic Thermal Management,
> such as the thermal framework.
We are talking cellphone here. Yes, sensor may be inacurate (but it
seems to work pretty well; perhaps TI can point us to some docs that
explains the details?), but it provides useful information (mostly
room temperature). I don't think we'll ever run anywhere close to
thermal limits where inacuracy would matter. (Battery can't really
take > 60C. AFAICT CPU limit is 120C. Battery is close to the CPU.)
> > Signed-off-by: Pavel Machek
> >
> > diff --git a/drivers/thermal/ti-soc-thermal/Kconfig
> > b/drivers/thermal/ti-soc-thermal/Kconfig
> > index bd4c7be..a49495f 100644
> > --- a/drivers/thermal/ti-soc-thermal/Kconfig
> > +++ b/drivers/thermal/ti-soc-thermal/Kconfig
> > @@ -21,6 +21,15 @@ config TI_THERMAL
> > This includes trip points definitions, extrapolation rules and
> > CPU cooling device bindings.
> >
> > +config OMAP3_THERMAL
> > + bool "Texas Instruments OMAP3 thermal support"
> > + depends on TI_SOC_THERMAL
> > + depends on ARCH_OMAP3
> > + help
> > + If you say yes here you get thermal support for the Texas Instruments
> > + OMAP3 SoC family. The current chip supported are:
> > + - OMAP3430
>
> But if you insist :-), I believe the user deserves at least a fair
> message saying this is on his / her own risk.
Something like this?
If you say yes here you get thermal support for the Texas Instruments
OMAP3 SoC family. The current chip supported are:
- OMAP3430
OMAP3 chips normally don't need thermal management, and sensors in
this generation are not very accurate, nor they are very close to
the important hotspots.
Say 'N' here.
> > +static struct temp_sensor_registers
> > +omap34xx_mpu_temp_sensor_registers = {
> > + .temp_sensor_ctrl = 0,
> > + .bgap_tempsoff_mask = 0, /* Unused, we don't have POWER_SWITCH */
> > + .bgap_soc_mask = BIT(8),
> > + .bgap_eocz_mask = BIT(7),
> > + .bgap_dtemp_mask = 0x7f,
> > +
> > + .bgap_mode_ctrl = 0,
> > + .mode_ctrl_mask = BIT(9),
> > +
> > + .bgap_efuse = 0,
>
> The 0'ed filed may be removed here.
Ok; I'll keep temp_sensors_ctrl / bgap_mode_ctrl, because it is actually used.
> > diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> > b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> > index 634b6ce..3b4e72f 100644
> > --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> > +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> > @@ -1509,6 +1531,12 @@ static SIMPLE_DEV_PM_OPS(ti_bandgap_dev_pm_ops,
> > ti_bandgap_suspend,
> > #endif
> >
> > static const struct of_device_id of_ti_bandgap_match[] = {
> > +#ifdef CONFIG_OMAP3_THERMAL
> > + {
> > + .compatible = "ti,omap34xx-bandgap",
>
> This needs to be updated in the binding documentation.
> Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
Ok.
> > + .data = (void *)_data,
>
>
> Having a run time message intentionally advising users of the risk of
> using this sensor is also required.
Ok, what about?
if (TI_BANDGAP_HAS(bgp, UNRELIABLE))
dev_warn(>dev,
"OMAP3 thermal sensor is unreliable and normally
unneccessary\n");
Will not fit in 80 columns, but keeping message on one line is more important.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
[PATCH] g_NCR5380: Kill compiler warning if builtin
If CONFIG_SCSI_GENERIC_NCR5380=y:
drivers/scsi/g_NCR5380.c:727: warning: ‘id_table’ defined but not used
In the non-modular case, MODULE_DEVICE_TABLE() expands to nothing, and
id_table is not referenced.
Correct the existing #ifdef to fix this.
Signed-off-by: Geert Uytterhoeven
---
drivers/scsi/g_NCR5380.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index f35792f7051c0884..74ec2f5669aba5f5 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -723,7 +723,7 @@ module_param(ncr_53c400a, int, 0);
module_param(dtc_3181e, int, 0);
MODULE_LICENSE("GPL");
-#ifndef SCSI_G_NCR5380_MEM
+#if !defined(SCSI_G_NCR5380_MEM) && defined(MODULE)
static struct isapnp_device_id id_table[] = {
{
ISAPNP_ANY_ID, ISAPNP_ANY_ID,
--
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] thermal: of: Remove bogus type qualifier for of_thermal_get_trip_points()
With gcc 4.1.2, 4.2, and 4.2.4 (4.4 and later are OK):
drivers/thermal/thermal_core.h:110: warning: type qualifiers ignored on
function return type
Signed-off-by: Geert Uytterhoeven
Fixes: ce8be7785922de0e ("thermal: of: Extend of-thermal to export table of
trip points")
---
drivers/thermal/of-thermal.c | 2 +-
drivers/thermal/thermal_core.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index e145b66df444e65b..d717f3dab6f1410f 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -149,7 +149,7 @@ EXPORT_SYMBOL_GPL(of_thermal_is_trip_valid);
*
* Return: pointer to trip points table, NULL otherwise
*/
-const struct thermal_trip * const
+const struct thermal_trip *
of_thermal_get_trip_points(struct thermal_zone_device *tz)
{
struct __thermal_zone *data = tz->devdata;
diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
index 9083e75206236c19..0531c752fbbb6680 100644
--- a/drivers/thermal/thermal_core.h
+++ b/drivers/thermal/thermal_core.h
@@ -91,7 +91,7 @@ int of_parse_thermal_zones(void);
void of_thermal_destroy_zones(void);
int of_thermal_get_ntrips(struct thermal_zone_device *);
bool of_thermal_is_trip_valid(struct thermal_zone_device *, int);
-const struct thermal_trip * const
+const struct thermal_trip *
of_thermal_get_trip_points(struct thermal_zone_device *);
#else
static inline int of_parse_thermal_zones(void) { return 0; }
@@ -105,7 +105,7 @@ static inline bool of_thermal_is_trip_valid(struct
thermal_zone_device *tz,
{
return 0;
}
-static inline const struct thermal_trip * const
+static inline const struct thermal_trip *
of_thermal_get_trip_points(struct thermal_zone_device *tz)
{
return NULL;
--
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] x86, um: actually mark system call tables readonly
Am 03.01.2015 um 13:11 schrieb Daniel Borkmann:
> Commit a074335a370e ("x86, um: Mark system call tables readonly") was
> supposed to mark the sys_call_table in UML as RO by adding the const,
> but it doesn't have the desired effect as it's nevertheless being placed
> into the data section since __cacheline_aligned enforces sys_call_table
> being placed into .data..cacheline_aligned instead. We need to use
> the cacheline_aligned version instead to fix this issue.
__ vs. ___ oh my...
I'll pick up this patch.
Thanks a lot Daniel!
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] of/pci: add of_pci_dma_configure() update dma configuration
On Friday 02 January 2015 17:33:53 Murali Karicheri wrote: > > I have no experience with IOMMU and may not offer much help here as I > originally wrote above. Will Deacon has added this API and probably able > to offer some help in this discussion. > > Will Deacon, > > Any comment? It's complicated :( > Looking at the iommu documentation and of_iommu.c, I get a feeling that > this API is not really used at present as there are no callers of > of_iommu_set_ops() and I assume this is a WIP. Right, but we have patches for some iommu drivers based on this API, and we should migrate all of them eventually. > I believe the way it is > expected to work is to have the iommu driver of the master IOMMU devices > call of_iommu_set_ops(). The device node of this master IOMMU device is > specified as a phandle in the OF node of the device (various bus devices > such as platform, PCI etc). This allow to retrieve the iommu ops though > the of_iommu_configure() API and use it in arch_setup_dma_ops(). So my > gut feeling is that for PCI devices, as there are no DT node, the root > bus node may specify iommus phandle to IOMMU master OF nodes. Yes, but we also need to pass a PCI device specific identifier along with the root bus node, because some iommu drivers take the PCI bus/device/function number into account for creating per-function i/o page tables. > W.r.t your comment "We may want to address the comment in > of_iommu_configure about parent nodes. We should be sure these changes > work with how we would do searching parent nodes", > > I believe, the parent node search itself should work the same way in the > case of PCI as with platform bus case. PCI's case, we are providing the > OF node of the root bus host bridge. Why should this be any different in > terms of search? > > I see a potential issue with dma-ranges as described in the notes below. > As noted below the usage of dma-range for iommu is to be determined. For > keystone, the of_iommu_configure() always return false as we don't use > the iommu. But don't know if this has any consequences for other > platforms. Or I got your questions wrong. Any help here from others on > the list? > > > One possible extension to the above is to use an "iommus" property along > with a "dma-ranges" property in a bus device node (such as PCI host > bridges). This can be useful to describe how children on the bus relate > to the IOMMU if they are not explicitly listed in the device tree (e.g. > PCI devices). However, the requirements of that use-case haven't been > fully determined yet. Implementing this is therefore not recommended > without further discussion and extension of this binding. > = This probably won't ever apply to PCI devices, so let's ignore it for now. For the moment (and for PCI), we should assume that we either configure an iommu directly or we use dma-ranges if no iommu is in use. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
0002-Spi-spi-gpio-fixed-spaces-coding-style-issue.patch
>From 00454f12a304489125bbdfbc2f50de3c2b9d49d3 Mon Sep 17 00:00:00 2001
From: Nizam Haider
Date: Sun, 4 Jan 2015 00:24:38 +0530
Subject: [PATCH 2/2] Spi: spi-gpio: fixed spaces coding style issue
Fixed a coding style issue.
Signed-off-by: Nizam Haider
---
drivers/spi/spi-gpio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index aee4e75..702b0b8 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -92,7 +92,7 @@ struct spi_gpio {
/*--*/
-static inline struct spi_gpio * __pure
+static inline struct spi_gpio *__pure
spi_to_spi_gpio(const struct spi_device *spi)
{
const struct spi_bitbang *bang;
@@ -103,7 +103,7 @@ spi_to_spi_gpio(const struct spi_device *spi)
return spi_gpio;
}
-static inline struct spi_gpio_platform_data * __pure
+static inline struct spi_gpio_platform_data *__pure
spi_to_pdata(const struct spi_device *spi)
{
return _to_spi_gpio(spi)->pdata;
--
1.8.1.4
Re: [PATCHv5 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
On Fri 2015-01-02 21:11:17, Samuel Thibault wrote: > Pavel Machek, le Fri 02 Jan 2015 20:53:51 +0100, a écrit : > > input4::capsl/trigger was none by default, that can't be right, right? > > Indeed. And I don't see how it can be that way, since the input4::capsl > LED and the input4-capsl trigger get initialized at the same time in > input_led_connect... (and the order does not matter since both will > try to connect to the other on registration). > > > I tried putting kbd-capslock and input4-capsl there, but that did not > > seem to help. > > That should have. > > > It works with heartbeat trigger, but not with input4-numl > > trigger. > > It should have worked with input4-numl too. > > > vt::capsl/brightness controls capslock led, even when > > input4-capsl/trigger is set to input4-numl. > > It shouldn't. > > > Confused, > > I guess I'm even more. I had tested everything that you have described, > without any issue, on both an internal laptop keyboard and an external > USB keyboard, and have tested again just now, with the same success. > > Which hardware setup do you have, more precisely? I tested on Thinkpad X60, with internal keyboard. (PS/2, I'd say). I let Debian boot into graphical login prompt, switched to text console, and did the testing there. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 0/9 net-next v2] rhashtable: Per bucket locks & deferred table resizing
From: Thomas Graf Date: Fri, 2 Jan 2015 23:00:13 +0100 > Prepares for and introduces per bucket spinlocks and deferred table > resizing. This allows for parallel table mutations in different hash > buckets from atomic context. The resizing occurs in the background > in a separate worker thread while lookups, inserts, and removals can > continue. > > Also modified the chain linked list to be terminated with a special > nulls marker to allow entries to move between multiple lists. > > Last but not least, reintroduces lockless netlink_lookup() with > deferred Netlink socket destruction to avoid the side effect of > increased netlink_release() runtime. I'm sure that this might need a minor tweak or two still, but I really like how you implemented this so I'll apply this series now. 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: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell Date: Sat, 3 Jan 2015 09:11:01 +1100 > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > drivers/net/ethernet/mellanox/mlx4/en_clock.c: In function > 'mlx4_en_init_timestamp': > drivers/net/ethernet/mellanox/mlx4/en_clock.c:249:2: error: implicit > declaration of function 'CLOCKSOURCE_MASK' > [-Werror=implicit-function-declaration] > mdev->cycles.mask = CLOCKSOURCE_MASK(48); Stephen please let me know if this failure is persisting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] MAINTAINERS: Add linux-omap to list of reviewers for TI Thermal
Add linux-omap mailing list to the TI THERMAL list for wider review. Reported-by: Pavel Machek Signed-off-by: Nishanth Menon --- MAINTAINERS |1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index ddb9ac8..dc9efd5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9533,6 +9533,7 @@ F:drivers/platform/x86/thinkpad_acpi.c TI BANDGAP AND THERMAL DRIVER M: Eduardo Valentin L: linux...@vger.kernel.org +L: linux-o...@vger.kernel.org S: Supported F: drivers/thermal/ti-soc-thermal/ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cleanup ti-soc-thermal
On Sat 2015-01-03 12:57:04, Nishanth Menon wrote: > On 01/03/2015 12:51 PM, Pavel Machek wrote: > >On Sat 2015-01-03 11:48:04, Nishanth Menon wrote: > >>On 12:19-20150103, Pavel Machek wrote: > >>>Simplify code by removing goto's where they point to simple return. > >>> > >>>Avoid confusing |= on error values. > >> > >>Please split these up into chunks of related changes. there is white > >>space and quiet a few other changes all mixed in. > > > >Do you believe that the patch is too big to be understood? I don't > >think it is. > > > >It is four screens, and it is pretty obvious it does not change any > >code. > > It basic patch generation stuff - where you are being nice to the reviewer. > When you are doing functional changes, at least drop out or at the very > least mention that there are white space changes in your patch > submission. Original submission said: # Correct whitespace. Some maintainers actually hate separate whitespace changes; talk to Al Viro some day. > I dont care too much to review stuff where I have to look at multiple > changes in a single patch - trivial or not. Sorry.. just a waste of my time. If 4 screens of trivial changes are too much for you, don't review trivial patches, then. It is not your job. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
[RFC] netlink: get rid of nl_table_lock
As a follow on to Thomas's patch I think this would complete the
transistion to RCU for netlink.
Compile tested only.
This patch gets rid of the reader/writer nl_table_lock and replaces it
with exclusively using RCU for reading, and a mutex for writing.
Signed-off-by: Stephen Hemminger
--- a/include/net/sock.h2015-01-01 10:05:35.805253771 -0800
+++ b/include/net/sock.h2015-01-03 10:45:29.661737618 -0800
@@ -666,6 +666,8 @@ static inline void sk_add_bind_node(stru
hlist_for_each_entry_safe(__sk, tmp, list, sk_node)
#define sk_for_each_bound(__sk, list) \
hlist_for_each_entry(__sk, list, sk_bind_node)
+#define sk_for_each_bound_rcu(__sk, list) \
+ hlist_for_each_entry_rcu(__sk, list, sk_bind_node)
/**
* sk_nulls_for_each_entry_offset - iterate over a list at a given struct
offset
--- a/net/netlink/af_netlink.c 2015-01-03 10:04:37.738319202 -0800
+++ b/net/netlink/af_netlink.c 2015-01-03 10:53:29.568387253 -0800
@@ -100,15 +100,14 @@ static void netlink_skb_destructor(struc
* Lookup and traversal are protected with an RCU read-side lock. Insertion
* and removal are protected with nl_sk_hash_lock while using RCU list
* modification primitives and may run in parallel to RCU protected lookups.
- * Destruction of the Netlink socket may only occur *after* nl_table_lock has
+ * Destruction of the Netlink socket may only occur *after* nl_table_mutex has
* been acquired * either during or after the socket has been removed from
* the list and after an RCU grace period.
*/
-DEFINE_RWLOCK(nl_table_lock);
-EXPORT_SYMBOL_GPL(nl_table_lock);
-static atomic_t nl_table_users = ATOMIC_INIT(0);
+static DEFINE_MUTEX(nl_table_mutex);
-#define nl_deref_protected(X) rcu_dereference_protected(X,
lockdep_is_held(_table_lock));
+#define nl_deref_protected(X) \
+ rcu_dereference_protected(X, lockdep_is_held(_table_mutex))
/* Protects netlink socket hash table mutations */
DEFINE_MUTEX(nl_sk_hash_lock);
@@ -118,7 +117,8 @@ EXPORT_SYMBOL_GPL(nl_sk_hash_lock);
static int lockdep_nl_sk_hash_is_held(void *parent)
{
if (debug_locks)
- return lockdep_is_held(_sk_hash_lock) ||
lockdep_is_held(_table_lock);
+ return lockdep_is_held(_sk_hash_lock) ||
+ lockdep_is_held(_table_mutex);
return 1;
}
#endif
@@ -925,59 +925,14 @@ static void netlink_sock_destruct(struct
WARN_ON(nlk_sk(sk)->groups);
}
-/* This lock without WQ_FLAG_EXCLUSIVE is good on UP and it is _very_ bad on
- * SMP. Look, when several writers sleep and reader wakes them up, all but one
- * immediately hit write lock and grab all the cpus. Exclusive sleep solves
- * this, _but_ remember, it adds useless work on UP machines.
- */
-
void netlink_table_grab(void)
- __acquires(nl_table_lock)
{
- might_sleep();
-
- write_lock_irq(_table_lock);
-
- if (atomic_read(_table_users)) {
- DECLARE_WAITQUEUE(wait, current);
-
- add_wait_queue_exclusive(_table_wait, );
- for (;;) {
- set_current_state(TASK_UNINTERRUPTIBLE);
- if (atomic_read(_table_users) == 0)
- break;
- write_unlock_irq(_table_lock);
- schedule();
- write_lock_irq(_table_lock);
- }
-
- __set_current_state(TASK_RUNNING);
- remove_wait_queue(_table_wait, );
- }
+ mutex_lock(_table_mutex);
}
void netlink_table_ungrab(void)
- __releases(nl_table_lock)
-{
- write_unlock_irq(_table_lock);
- wake_up(_table_wait);
-}
-
-static inline void
-netlink_lock_table(void)
{
- /* read_lock() synchronizes us to netlink_table_grab */
-
- read_lock(_table_lock);
- atomic_inc(_table_users);
- read_unlock(_table_lock);
-}
-
-static inline void
-netlink_unlock_table(void)
-{
- if (atomic_dec_and_test(_table_users))
- wake_up(_table_wait);
+ mutex_unlock(_table_mutex);
}
struct netlink_compare_arg
@@ -1151,12 +1106,12 @@ static int netlink_create(struct net *ne
if (protocol < 0 || protocol >= MAX_LINKS)
return -EPROTONOSUPPORT;
- netlink_lock_table();
+ mutex_lock(_table_mutex);
#ifdef CONFIG_MODULES
if (!nl_table[protocol].registered) {
- netlink_unlock_table();
+ mutex_unlock(_table_mutex);
request_module("net-pf-%d-proto-%d", PF_NETLINK, protocol);
- netlink_lock_table();
+ mutex_lock(_table_mutex);
}
#endif
if (nl_table[protocol].registered &&
@@ -1167,7 +1122,7 @@ static int netlink_create(struct net *ne
cb_mutex = nl_table[protocol].cb_mutex;
bind = nl_table[protocol].bind;
unbind = nl_table[protocol].unbind;
- netlink_unlock_table();
+ mutex_unlock(_table_mutex);
if (err < 0)
Re: [PATCH] cleanup ti-soc-thermal
On 01/03/2015 12:51 PM, Pavel Machek wrote: On Sat 2015-01-03 11:48:04, Nishanth Menon wrote: On 12:19-20150103, Pavel Machek wrote: Simplify code by removing goto's where they point to simple return. Avoid confusing |= on error values. Please split these up into chunks of related changes. there is white space and quiet a few other changes all mixed in. Do you believe that the patch is too big to be understood? I don't think it is. It is four screens, and it is pretty obvious it does not change any code. It basic patch generation stuff - where you are being nice to the reviewer. When you are doing functional changes, at least drop out or at the very least mention that there are white space changes in your patch submission. I dont care too much to review stuff where I have to look at multiple changes in a single patch - trivial or not. Sorry.. just a waste of my time. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cleanup ti-soc-thermal
On Sat 2015-01-03 11:48:04, Nishanth Menon wrote: > On 12:19-20150103, Pavel Machek wrote: > > Simplify code by removing goto's where they point to simple return. > > > > Avoid confusing |= on error values. > > Please split these up into chunks of related changes. there is white > space and quiet a few other changes all mixed in. > > Also please cc linux-omap mailing list as well to get adequate > audience. Actually, if you want linux-omap list to be consistently cc-ed, you may want to update MAINTAINERS entry. Right now it says: TI BANDGAP AND THERMAL DRIVER M: Eduardo Valentin L: linux...@vger.kernel.org S: Supported F: drivers/thermal/ti-soc-thermal/ Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] cleanup ti-soc-thermal
On Sat 2015-01-03 11:48:04, Nishanth Menon wrote:
> On 12:19-20150103, Pavel Machek wrote:
> > Simplify code by removing goto's where they point to simple return.
> >
> > Avoid confusing |= on error values.
>
> Please split these up into chunks of related changes. there is white
> space and quiet a few other changes all mixed in.
Do you believe that the patch is too big to be understood? I don't
think it is.
It is four screens, and it is pretty obvious it does not change any
code.
If Eduardo asks me, I may do it, but it will waste my time, time of
everyone else on the list, and will not really improve anything.
[Patch left below, so others can see we are talking 4 screens of code.]
> Also please cc linux-omap mailing list as well to get adequate
> audience.
Can do.
Pavel
> >
> > Correct whitespace.
> >
> > Signed-off-by: Pavel Machek
> >
> > diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> > b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> > index 634b6ce..3b4e72f 100644
> > --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> > +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> > @@ -263,18 +264,13 @@ static
> > int ti_bandgap_adc_to_mcelsius(struct ti_bandgap *bgp, int adc_val, int *t)
> > {
> > const struct ti_bandgap_data *conf = bgp->conf;
> > - int ret = 0;
> >
> > /* look up for temperature in the table and return the temperature */
> > - if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val) {
> > - ret = -ERANGE;
> > - goto exit;
> > - }
> > + if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val)
> > + return -ERANGE;
> >
> > *t = bgp->conf->conv_table[adc_val - conf->adc_start_val];
> > -
> > -exit:
> > - return ret;
> > + return 0;
> > }
> >
> > /**
> > @@ -295,16 +291,14 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap
> > *bgp, long temp, int *adc)
> > {
> > const struct ti_bandgap_data *conf = bgp->conf;
> > const int *conv_table = bgp->conf->conv_table;
> > - int high, low, mid, ret = 0;
> > + int high, low, mid;
> >
> > low = 0;
> > high = conf->adc_end_val - conf->adc_start_val;
> > mid = (high + low) / 2;
> >
> > - if (temp < conv_table[low] || temp > conv_table[high]) {
> > - ret = -ERANGE;
> > - goto exit;
> > - }
> > + if (temp < conv_table[low] || temp > conv_table[high])
> > + return -ERANGE;
> >
> > while (low < high) {
> > if (temp < conv_table[mid])
> > @@ -315,9 +309,7 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp,
> > long temp, int *adc)
> > }
> >
> > *adc = conf->adc_start_val + low;
> > -
> > -exit:
> > - return ret;
> > + return 0;
> > }
> >
> > /**
> > @@ -343,13 +335,11 @@ int ti_bandgap_add_hyst(struct ti_bandgap *bgp, int
> > adc_val, int hyst_val,
> > */
> > ret = ti_bandgap_adc_to_mcelsius(bgp, adc_val, );
> > if (ret < 0)
> > - goto exit;
> > + return ret;
> >
> > temp += hyst_val;
> >
> > ret = ti_bandgap_mcelsius_to_adc(bgp, temp, sum);
> > -
> > -exit:
> > return ret;
> > }
> >
> > @@ -468,22 +458,18 @@ exit:
> > */
> > static inline int ti_bandgap_validate(struct ti_bandgap *bgp, int id)
> > {
> > - int ret = 0;
> > -
> > if (!bgp || IS_ERR(bgp)) {
> > pr_err("%s: invalid bandgap pointer\n", __func__);
> > - ret = -EINVAL;
> > - goto exit;
> > + return -EINVAL;
> > }
> >
> > if ((id < 0) || (id >= bgp->conf->sensor_count)) {
> > dev_err(bgp->dev, "%s: sensor id out of range (%d)\n",
> > __func__, id);
> > - ret = -ERANGE;
> > + return -ERANGE;
> > }
> >
> > -exit:
> > - return ret;
> > + return 0;
> > }
> >
> > /**
> > @@ -511,12 +497,10 @@ static int _ti_bandgap_write_threshold(struct
> > ti_bandgap *bgp, int id, int val,
> >
> > ret = ti_bandgap_validate(bgp, id);
> > if (ret)
> > - goto exit;
> > + return ret;
> >
> > -
[PATCH V3] ARM: dts: am57xx-beagle-x15: Add GPIO controlled fan node
TPS gpio now controls a 5v 500mA TL5209 regulator which may be supply
a fan (such as AFB02505HHB) over J1 connector for various purposes.
Provide device tree node to enable the same.
Signed-off-by: Nishanth Menon
---
V3: Rebased to v3.19-rc1, added label for GPIO fan (for future cooling device
reference)
V2: https://patchwork.kernel.org/patch/5445111/
V1: https://patchwork.kernel.org/patch/5444911/
Enable and disable can be controlled by (post the RPM, it finds
closest match - even a 1 will do)
echo '13000' > /sys/class/hwmon/hwmon0/fan1_target
and
echo '0' > /sys/class/hwmon/hwmon0/fan1_target
Test log: http://slexy.org/view/s2T0ajh46z
requires CONFIG_GPIO_PALMAS and CONFIG_SENSORS_GPIO_FAN to be operational
Applies on v3.19-rc1
arch/arm/boot/dts/am57xx-beagle-x15.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 6c2e8e4..c171720 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -80,6 +80,14 @@
default-state = "off";
};
};
+
+ gpio_fan: gpio_fan {
+ /* Based on 5v 500mA AFB02505HHB */
+ compatible = "gpio-fan";
+ gpios = <_gpio 1 GPIO_ACTIVE_HIGH>;
+ gpio-fan,speed-map = <00
+ 13000 1>;
+ };
};
_pmx_core {
@@ -394,6 +402,12 @@
wakeup-source;
ti,palmas-long-press-seconds = <12>;
};
+
+ tps659038_gpio: tps659038_gpio {
+ compatible = "ti,palmas-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
};
tmp102: tmp102@48 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert "ipw2200: select CFG80211_WEXT"
On Sat, Jan 3, 2015 at 10:02 AM, Marcel Holtmann wrote: > > why would you revert this? It is obviously the correct change to actually > select CFG80211_WEXT. I don't know about obvious, but yeah, I think the select in this case is actually the better idea anyway. We could make the CFG80211_WEXT help message be very negative so that people aren't encouraged to select it even if they can, but then if they need the ipw driver it gets selected because of that. Because the ipw driver is probably the more important of the two if you just happen to have old hardware but are upgrading yout software (and anybody who recompiles their own kernel is obviously doing the latter). 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: [PATCH] Revert "ipw2200: select CFG80211_WEXT"
Hi Paul,
> This reverts commit 60220f41775e634258efd1b54c6fa81ce706.
>
> The raison d'être of commit 60220f41 ("ipw2200: select
> CFG80211_WEXT") was reverted in commit 2d36e008739e ("Revert "cfg80211:
> make WEXT compatibility unselectable""). So revert this commit too.
>
> Signed-off-by: Paul Bolle
> ---
> drivers/net/wireless/ipw2x00/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ipw2x00/Kconfig
> b/drivers/net/wireless/ipw2x00/Kconfig
> index 21de4fe6cf2d..91c0cb3c368e 100644
> --- a/drivers/net/wireless/ipw2x00/Kconfig
> +++ b/drivers/net/wireless/ipw2x00/Kconfig
> @@ -65,8 +65,7 @@ config IPW2100_DEBUG
>
> config IPW2200
> tristate "Intel PRO/Wireless 2200BG and 2915ABG Network Connection"
> - depends on PCI && CFG80211
> - select CFG80211_WEXT
> + depends on PCI && CFG80211 && CFG80211_WEXT
> select WIRELESS_EXT
> select WEXT_SPY
> select WEXT_PRIV
why would you revert this? It is obviously the correct change to actually
select CFG80211_WEXT.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] power: avs: smartreflex: Remove unused function
On 16:58-20150103, Rickard Strandqvist wrote:
> Remove the function sr_configure_minmax() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/power/avs/smartreflex.c | 86
> -
> include/linux/power/smartreflex.h |1 -
> 2 files changed, 87 deletions(-)
>
> diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
> index db9973b..62b8351 100644
> --- a/drivers/power/avs/smartreflex.c
> +++ b/drivers/power/avs/smartreflex.c
> @@ -460,92 +460,6 @@ int sr_disable_errgen(struct omap_sr *sr)
> }
>
> /**
> - * sr_configure_minmax() - Configures the SmartReflex to perform AVS using
> the
> - *minmaxavg module.
> - * @sr: SR module to be configured.
> - *
> - * This API is to be called from the smartreflex class driver to
> - * configure the minmaxavg module inside the smartreflex module.
> - * SR settings if using the ERROR module inside Smartreflex.
> - * SR CLASS 3 by default uses only the ERROR module where as
> - * SR CLASS 2 can choose between ERROR module and MINMAXAVG
> - * module. Returns 0 on success and error value in case of failure.
> - */
> -int sr_configure_minmax(struct omap_sr *sr)
> -{
> - u32 sr_config, sr_avgwt;
> - u32 senp_en = 0, senn_en = 0;
> - u8 senp_shift, senn_shift;
> -
> - if (!sr) {
> - pr_warn("%s: NULL omap_sr from %pF\n", __func__,
> - (void *)_RET_IP_);
> - return -EINVAL;
> - }
> -
> - if (!sr->clk_length)
> - sr_set_clk_length(sr);
> -
> - senp_en = sr->senp_mod;
> - senn_en = sr->senn_mod;
> -
> - sr_config = (sr->clk_length << SRCONFIG_SRCLKLENGTH_SHIFT) |
> - SRCONFIG_SENENABLE |
> - (sr->accum_data << SRCONFIG_ACCUMDATA_SHIFT);
> -
> - switch (sr->ip_type) {
> - case SR_TYPE_V1:
> - sr_config |= SRCONFIG_DELAYCTRL;
> - senn_shift = SRCONFIG_SENNENABLE_V1_SHIFT;
> - senp_shift = SRCONFIG_SENPENABLE_V1_SHIFT;
> - break;
> - case SR_TYPE_V2:
> - senn_shift = SRCONFIG_SENNENABLE_V2_SHIFT;
> - senp_shift = SRCONFIG_SENPENABLE_V2_SHIFT;
> - break;
> - default:
> - dev_err(>pdev->dev, "%s: Trying to Configure smartreflex"
> - "module without specifying the ip\n", __func__);
> - return -EINVAL;
> - }
> -
> - sr_config |= ((senn_en << senn_shift) | (senp_en << senp_shift));
> - sr_write_reg(sr, SRCONFIG, sr_config);
> - sr_avgwt = (sr->senp_avgweight << AVGWEIGHT_SENPAVGWEIGHT_SHIFT) |
> - (sr->senn_avgweight << AVGWEIGHT_SENNAVGWEIGHT_SHIFT);
> - sr_write_reg(sr, AVGWEIGHT, sr_avgwt);
> -
> - /*
> - * Enabling the interrupts if MINMAXAVG module is used.
> - * TODO: check if all the interrupts are mandatory
> - */
> - switch (sr->ip_type) {
> - case SR_TYPE_V1:
> - sr_modify_reg(sr, ERRCONFIG_V1,
> - (ERRCONFIG_MCUACCUMINTEN | ERRCONFIG_MCUVALIDINTEN |
> - ERRCONFIG_MCUBOUNDINTEN),
> - (ERRCONFIG_MCUACCUMINTEN | ERRCONFIG_MCUACCUMINTST |
> - ERRCONFIG_MCUVALIDINTEN | ERRCONFIG_MCUVALIDINTST |
> - ERRCONFIG_MCUBOUNDINTEN | ERRCONFIG_MCUBOUNDINTST));
> - break;
> - case SR_TYPE_V2:
> - sr_write_reg(sr, IRQSTATUS,
> - IRQSTATUS_MCUACCUMINT | IRQSTATUS_MCVALIDINT |
> - IRQSTATUS_MCBOUNDSINT | IRQSTATUS_MCUDISABLEACKINT);
> - sr_write_reg(sr, IRQENABLE_SET,
> - IRQENABLE_MCUACCUMINT | IRQENABLE_MCUVALIDINT |
> - IRQENABLE_MCUBOUNDSINT | IRQENABLE_MCUDISABLEACKINT);
> - break;
> - default:
> - dev_err(>pdev->dev, "%s: Trying to Configure smartreflex"
> - "module without specifying the ip\n", __func__);
> - return -EINVAL;
> - }
> -
> - return 0;
> -}
> -
> -/**
> * sr_enable() - Enables the smartreflex module.
> * @sr: pointer to which the SR module to be configured belongs
> to.
> * @volt:The voltage at which the Voltage domain associated with
> diff --git a/include/linux/power/smartreflex.h
> b/include/linux/power/smartreflex.h
> index d8b187c3..ffd31af 100
[PATCH] device: Fix dev_dbg_once macro
There is a copy/paste typo in the dev_dbg_once macro.
It uses dev_info instead of dev_dbg, so use the correct
function instead.
Signed-off-by: Joe Perches
Noticed-by: Marc Finet
---
include/linux/device.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index fb50673..7b25323 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1156,7 +1156,7 @@ do {
\
#define dev_info_once(dev, fmt, ...) \
dev_level_once(dev_info, dev, fmt, ##__VA_ARGS__)
#define dev_dbg_once(dev, fmt, ...)\
- dev_level_once(dev_info, dev, fmt, ##__VA_ARGS__)
+ dev_level_once(dev_dbg, dev, fmt, ##__VA_ARGS__)
#define dev_level_ratelimited(dev_level, dev, fmt, ...)
\
do { \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cleanup ti-soc-thermal
On 12:19-20150103, Pavel Machek wrote:
> Simplify code by removing goto's where they point to simple return.
>
> Avoid confusing |= on error values.
Please split these up into chunks of related changes. there is white
space and quiet a few other changes all mixed in.
Also please cc linux-omap mailing list as well to get adequate audience.
>
> Correct whitespace.
>
> Signed-off-by: Pavel Machek
>
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> index 634b6ce..3b4e72f 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> @@ -263,18 +264,13 @@ static
> int ti_bandgap_adc_to_mcelsius(struct ti_bandgap *bgp, int adc_val, int *t)
> {
> const struct ti_bandgap_data *conf = bgp->conf;
> - int ret = 0;
>
> /* look up for temperature in the table and return the temperature */
> - if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val) {
> - ret = -ERANGE;
> - goto exit;
> - }
> + if (adc_val < conf->adc_start_val || adc_val > conf->adc_end_val)
> + return -ERANGE;
>
> *t = bgp->conf->conv_table[adc_val - conf->adc_start_val];
> -
> -exit:
> - return ret;
> + return 0;
> }
>
> /**
> @@ -295,16 +291,14 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp,
> long temp, int *adc)
> {
> const struct ti_bandgap_data *conf = bgp->conf;
> const int *conv_table = bgp->conf->conv_table;
> - int high, low, mid, ret = 0;
> + int high, low, mid;
>
> low = 0;
> high = conf->adc_end_val - conf->adc_start_val;
> mid = (high + low) / 2;
>
> - if (temp < conv_table[low] || temp > conv_table[high]) {
> - ret = -ERANGE;
> - goto exit;
> - }
> + if (temp < conv_table[low] || temp > conv_table[high])
> + return -ERANGE;
>
> while (low < high) {
> if (temp < conv_table[mid])
> @@ -315,9 +309,7 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp,
> long temp, int *adc)
> }
>
> *adc = conf->adc_start_val + low;
> -
> -exit:
> - return ret;
> + return 0;
> }
>
> /**
> @@ -343,13 +335,11 @@ int ti_bandgap_add_hyst(struct ti_bandgap *bgp, int
> adc_val, int hyst_val,
>*/
> ret = ti_bandgap_adc_to_mcelsius(bgp, adc_val, );
> if (ret < 0)
> - goto exit;
> + return ret;
>
> temp += hyst_val;
>
> ret = ti_bandgap_mcelsius_to_adc(bgp, temp, sum);
> -
> -exit:
> return ret;
> }
>
> @@ -468,22 +458,18 @@ exit:
> */
> static inline int ti_bandgap_validate(struct ti_bandgap *bgp, int id)
> {
> - int ret = 0;
> -
> if (!bgp || IS_ERR(bgp)) {
> pr_err("%s: invalid bandgap pointer\n", __func__);
> - ret = -EINVAL;
> - goto exit;
> + return -EINVAL;
> }
>
> if ((id < 0) || (id >= bgp->conf->sensor_count)) {
> dev_err(bgp->dev, "%s: sensor id out of range (%d)\n",
> __func__, id);
> - ret = -ERANGE;
> + return -ERANGE;
> }
>
> -exit:
> - return ret;
> + return 0;
> }
>
> /**
> @@ -511,12 +497,10 @@ static int _ti_bandgap_write_threshold(struct
> ti_bandgap *bgp, int id, int val,
>
> ret = ti_bandgap_validate(bgp, id);
> if (ret)
> - goto exit;
> + return ret;
>
> - if (!TI_BANDGAP_HAS(bgp, TALERT)) {
> - ret = -ENOTSUPP;
> - goto exit;
> - }
> + if (!TI_BANDGAP_HAS(bgp, TALERT))
> + return -ENOTSUPP;
>
> ts_data = bgp->conf->sensors[id].ts_data;
> tsr = bgp->conf->sensors[id].registers;
> @@ -529,17 +513,15 @@ static int _ti_bandgap_write_threshold(struct
> ti_bandgap *bgp, int id, int val,
> }
>
> if (ret)
> - goto exit;
> + return ret;
>
> ret = ti_bandgap_mcelsius_to_adc(bgp, val, _val);
> if (ret < 0)
> - goto exit;
> + return ret;
>
> spin_lock(>lock);
> ret = ti_bandgap_update_alert_threshold(bgp, id, adc_val, hot);
> spin_unlock(>lock);
> -
> -exit:
> return ret;
> }
>
> @@ -582,7 +564,7 @@ static int _ti_bandgap_read_threshold(struct ti_bandgap
> *bgp, int id,
>
>
[PATCH] [sched] Account the elapse of each period accurately
Currently, the decayed values of previous periods can spill into the lower 10
bits of
runnable_avg_period. This makes the next period to be less than 1024 us. If we
want
to decay exactly every 1024us, which I see no reason not to (less math overhead
and
consistent decay period among all tasks), we can use a separate field to track
how
much time the current period has elapsed instead of overloading
runnable_avg_period.
This patch achieves this.
Signed-off-by: Zhihui Zhang
---
include/linux/sched.h | 2 +-
kernel/sched/fair.c | 5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 8db31ef..fa6b23b 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1116,7 +1116,7 @@ struct sched_avg {
* above by 1024/(1-y). Thus we only need a u32 to store them for all
* choices of y < 1-2^(-32)*1024.
*/
- u32 runnable_avg_sum, runnable_avg_period;
+ u32 accrue, runnable_avg_sum, runnable_avg_period;
u64 last_runnable_update;
s64 decay_count;
unsigned long load_avg_contrib;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index df2cdf7..c87ecf5 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -676,6 +676,7 @@ void init_task_runnable_average(struct task_struct *p)
{
u32 slice;
+ p->se.avg.accrue = 0;
p->se.avg.decay_count = 0;
slice = sched_slice(task_cfs_rq(p), >se) >> 10;
p->se.avg.runnable_avg_sum = slice;
@@ -2526,11 +2527,12 @@ static __always_inline int
__update_entity_runnable_avg(u64 now,
sa->last_runnable_update = now;
/* delta_w is the amount already accumulated against our next period */
- delta_w = sa->runnable_avg_period % 1024;
+ delta_w = sa->accrue;
if (delta + delta_w >= 1024) {
/* period roll-over */
decayed = 1;
+ sa->accrue = 0;
/*
* Now that we know we're crossing a period boundary, figure
* out how much from delta we need to complete the current
@@ -2558,6 +2560,7 @@ static __always_inline int
__update_entity_runnable_avg(u64 now,
sa->runnable_avg_sum += runnable_contrib;
sa->runnable_avg_period += runnable_contrib;
}
+ sa->accrue += delta;
/* Remainder of delta accrued against u_0` */
if (runnable)
--
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: WARNING: at drivers/gpu/drm/i915/intel_display.c:11375 [i915] in 3.19-rc2
On Fri, Jan 02, 2015 at 08:27:29PM +0530, Sudip Mukherjee wrote: > On Thu, Jan 01, 2015 at 05:22:15PM +0300, Andrey Skvortsov wrote: > > Hi, > > > > this warning does not exist in 3.19-rc1, but it happens every boot in > > 3.19-rc2. If you need any other information or data, I would be glad > > to help to debug it. > > mine is also i915, but i am not seeing any warning. if you send me your > .config, then i can try booting using that. > the current kernel version is : 3.19.0-rc2-next-20141231+ > Sorry, my first message was not fully correct. As I tried to bisect this, I noticed that this warning happens unfortunately not every boot. And I noticed another strange behavior. If the same kernel is always booted, the warning happens very seldom. To make it appear more frequently I booted v3.19-rc2 and v3.19-rc1-g08b022a9655bf one after another many times. In this case it happens with probability around 50% during the boot. my config is attached. -- Best regards, Andrey Skvortsov Secure e-mail with gnupg: See http://www.gnupg.org/ PGP Key ID: 0x57A3AEAD config.xz Description: Binary data signature.asc Description: Digital signature
[PATCH 1/1 linux-next] ceph: use %zu for size_t display
Fixes the following 32-bit compilation warning:
fs/ceph/addr.c:1419:2: warning: format '%lu' expects argument of type
'long unsigned int', but argument 5 has type 'size_t' [-Wformat=]
Signed-off-by: Fabian Frederick
---
fs/ceph/addr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index f5013d9..c81c0e0 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -1416,7 +1416,7 @@ void ceph_fill_inline_data(struct inode *inode, struct
page *locked_page,
}
}
- dout("fill_inline_data %p %llx.%llx len %lu locked_page %p\n",
+ dout("fill_inline_data %p %llx.%llx len %zu locked_page %p\n",
inode, ceph_vinop(inode), len, locked_page);
if (len > 0) {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Please Confirm
Is your email still active? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] next: microblaze: Fix build failure
On Sat, Jan 03, 2015 at 06:53:20AM -0800, Guenter Roeck wrote: > Microblaze build in linux-next fails with > > arch/microblaze/kernel/timer.c:224:2: error: > implicit declaration of function 'timecounter_init' > > Caused by missing include file in microblaze timer code. Already fixed in net-next. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] blackfin: mach-common: ints-priority: Remove unused function
Remove the function bfin_sec_resume() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
arch/blackfin/mach-common/ints-priority.c |8
1 file changed, 8 deletions(-)
diff --git a/arch/blackfin/mach-common/ints-priority.c
b/arch/blackfin/mach-common/ints-priority.c
index dd2af74..7236bdf 100644
--- a/arch/blackfin/mach-common/ints-priority.c
+++ b/arch/blackfin/mach-common/ints-priority.c
@@ -429,14 +429,6 @@ static void init_software_driven_irq(void)
bfin_sec_enable_ssi(37);
}
-void bfin_sec_resume(void)
-{
- bfin_write_SEC_SCI(0, SEC_CCTL, SEC_CCTL_RESET);
- udelay(100);
- bfin_write_SEC_GCTL(SEC_GCTL_EN);
- bfin_write_SEC_SCI(0, SEC_CCTL, SEC_CCTL_EN | SEC_CCTL_NMI_EN);
-}
-
void handle_sec_sfi_fault(uint32_t gstat)
{
--
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: WARNING: at drivers/gpu/drm/i915/intel_display.c:11375 [i915] in 3.19-rc2
On Fri, Jan 02, 2015 at 09:42:01AM +0200, Jani Nikula wrote: > On Thu, 01 Jan 2015, Andrey Skvortsov wrote: > > Hi, > > > > this warning does not exist in 3.19-rc1, but it happens every boot in > > 3.19-rc2. If you need any other information or data, I would be glad > > to help to debug it. > > Hmm, at a glance I can't find a commit that could be the culprit. Can > you bisect between rc1 and rc2 to find the bad commit? Sorry, my first message was not fully correct. As I tested this more, it happens unfortunately not every boot. And this is not a regression, because it happened couple of times with 3.19-rc1 too. This warning seems to depend on the previously booted kernel. If I boot the same kernel every time, it occurs very seldom. To reproduce the warning I booted v3.19-rc2 and v3.19-rc1-g08b022a965 one after another many times. In this case the warning happens with probability around 50%. > > [ 12.848428] [ cut here ] > > [ 12.848479] WARNING: CPU: 1 PID: 328 at > > drivers/gpu/drm/i915/intel_display.c:11375 > > intel_crtc_set_config+0x3de/0xb36 [i915]() > > [ 12.848482] WARN_ON(!set->fb && (set->num_connectors != 0)) -- Best regards, Andrey Skvortsov Secure e-mail with gnupg: See http://www.gnupg.org/ PGP Key ID: 0x57A3AEAD signature.asc Description: Digital signature
[PATCH] arm: mach-versatile: core: Remove unused function
Remove the function versatile_leds_event() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
arch/arm/mach-versatile/core.c | 37 -
1 file changed, 37 deletions(-)
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 08fb8c8..6ea09fe 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -728,43 +728,6 @@ struct of_dev_auxdata versatile_auxdata_lookup[]
__initdata = {
};
#endif
-#ifdef CONFIG_LEDS
-#define VA_LEDS_BASE (__io_address(VERSATILE_SYS_BASE) +
VERSATILE_SYS_LED_OFFSET)
-
-static void versatile_leds_event(led_event_t ledevt)
-{
- unsigned long flags;
- u32 val;
-
- local_irq_save(flags);
- val = readl(VA_LEDS_BASE);
-
- switch (ledevt) {
- case led_idle_start:
- val = val & ~VERSATILE_SYS_LED0;
- break;
-
- case led_idle_end:
- val = val | VERSATILE_SYS_LED0;
- break;
-
- case led_timer:
- val = val ^ VERSATILE_SYS_LED1;
- break;
-
- case led_halted:
- val = 0;
- break;
-
- default:
- break;
- }
-
- writel(val, VA_LEDS_BASE);
- local_irq_restore(flags);
-}
-#endif /* CONFIG_LEDS */
-
void versatile_restart(enum reboot_mode mode, const char *cmd)
{
void __iomem *sys = __io_address(VERSATILE_SYS_BASE);
--
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 V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
On 01/03/2015 10:16 AM, Tomasz Figa wrote: 2015-01-04 0:34 GMT+09:00 Nishanth Menon : On 15:40-20150103, Tomasz Figa wrote: Hi Nishanth, 2015-01-03 2:43 GMT+09:00 Nishanth Menon : AM437x generation of processors support programming the PL310 L2Cache controller's address filter start and end registers using a secure montior service. typo: s/montior/monitor/ [snip] Uggh.. yes indeed. I will post a v3 updating the comments. If the following is ok. + base = omap4_get_l2cache_base(); + filter_start = (reg == L310_ADDR_FILTER_START) ? val : + readl_relaxed(base + L310_ADDR_FILTER_START); + filter_end = (reg == L310_ADDR_FILTER_END) ? val : + readl_relaxed(base + L310_ADDR_FILTER_END); + omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start, + filter_end); + return; I don't have any significant comments about this patch in particular, but just noticed that you need to do read-backs here (and the typo thanks to the spell checker of my mailing app). Maybe you should consider switching to the .configure() API I introduced in my series? This would let you get rid of the hardcoded static mapping. Yeah, I have two choices there.. Either I provide the fundamental write function for the generic l2c code to use OR I provide a duplicate of resultant l2c_configure(aux write) + l2c310_configure. To allow for reuse of improvements or anything like errata implementations in the future, OMAP L2C implementation has chosen to provide the low level code and allow the higherlevel configure/write/whatever of the future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is not too complicated enough to warrant a replication of l2c310_configure. So, I prefer the current implementation than providing a .configure handler for outer_cache.configure from SoC level. Let me know if anyone has a strong objection to this. Well, what l2c310_configure() does after my series is just writing the registers. If they cannot be written normally (without some tricks such as reading back other registers) then IMHO a separate function should be provided. This is becomes possible after patch 3/8 (ARM: l2c: Add interface to ask hypervisor to configure L2C) and what is used on Exynos which also updates multiple registers in single SMC calls. You can find an example of use in patch 6/8 (ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310). What's even more interesting is that approaches similar to the one currently used on OMAP had been NAKed, when proposed for Exynos and this is why we have the solution proposed by my patches. Note that .write_sec() callback is still used for L2X0_CTRL and L2X0_DEBUG_CTRL registers, because there might be a need to write them separately (e.g. to disable the controller and to perform debug operations/workarounds when the controller is already enabled). we dont have a machine descriptor for configure instead we overide the logic(in you case after firmware load, in OMAP case, I need to figure out). my point being unlike the exynos configure code, OMAP code will look exactly like current pl310_configure-2 lines of code which really does not benefit anything. Thinking again, in fact, i'd rather drop this series than have to do a duplicated configure code(and force a resultant maintenance for the future) in OMAP code since none of OMAP4 or AM437x series need these patches. Interest for this series was non-mandatory, but just to be complete from SoC definition point of view. Let me know which way you guys want me to go. --- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] *** SUBJECT HERE ***
On Sat, Jan 03, 2015 at 02:06:22PM +0530, jitendra kumar khasdev wrote: > *** BLURB HERE *** What blurb? What subject? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] can: kvaser_usb: Don't free packets when tight on URBs
On Thu, Jan 01, 2015 at 01:59:13PM -0800, Stephen Hemminger wrote:
> On Tue, 23 Dec 2014 17:46:54 +0200
> "Ahmed S. Darwish" wrote:
>
> > int ret = NETDEV_TX_OK;
> > + bool kfree_skb_on_error = true;
> >
> > if (can_dropped_invalid_skb(netdev, skb))
> > return NETDEV_TX_OK;
> > @@ -1336,6 +1337,7 @@ static netdev_tx_t kvaser_usb_start_xmit(struct
> > sk_buff *skb,
> >
> > if (!context) {
> > netdev_warn(netdev, "cannot find free context\n");
> > + kfree_skb_on_error = false;
> > ret = NETDEV_TX_BUSY;
>
> You already have a flag value (ret == NETDEV_TX_BUSY), why
> not use that instead of introducing another variable?
Yes, that variable got implicitly removed in v2 patch 1/4.
Thanks,
--
Darwish
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scsi: aic7xxx: aic7xxx_core: Remove some unused functions
Removes some functions that are not used anywhere:
ahc_outq() ahc_inq()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/scsi/aic7xxx/aic7xxx_core.c | 26 --
drivers/scsi/aic7xxx/aic7xxx_inline.h |4
2 files changed, 30 deletions(-)
diff --git a/drivers/scsi/aic7xxx/aic7xxx_core.c
b/drivers/scsi/aic7xxx/aic7xxx_core.c
index 10172a3..6f91465 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_core.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_core.c
@@ -494,32 +494,6 @@ ahc_outl(struct ahc_softc *ahc, u_int port, uint32_t value)
ahc_outb(ahc, port+3, ((value) >> 24) & 0xFF);
}
-uint64_t
-ahc_inq(struct ahc_softc *ahc, u_int port)
-{
- return ((ahc_inb(ahc, port))
- | (ahc_inb(ahc, port+1) << 8)
- | (ahc_inb(ahc, port+2) << 16)
- | (ahc_inb(ahc, port+3) << 24)
- | (((uint64_t)ahc_inb(ahc, port+4)) << 32)
- | (((uint64_t)ahc_inb(ahc, port+5)) << 40)
- | (((uint64_t)ahc_inb(ahc, port+6)) << 48)
- | (((uint64_t)ahc_inb(ahc, port+7)) << 56));
-}
-
-void
-ahc_outq(struct ahc_softc *ahc, u_int port, uint64_t value)
-{
- ahc_outb(ahc, port, value & 0xFF);
- ahc_outb(ahc, port+1, (value >> 8) & 0xFF);
- ahc_outb(ahc, port+2, (value >> 16) & 0xFF);
- ahc_outb(ahc, port+3, (value >> 24) & 0xFF);
- ahc_outb(ahc, port+4, (value >> 32) & 0xFF);
- ahc_outb(ahc, port+5, (value >> 40) & 0xFF);
- ahc_outb(ahc, port+6, (value >> 48) & 0xFF);
- ahc_outb(ahc, port+7, (value >> 56) & 0xFF);
-}
-
/*
* Get a free scb. If there are none, see if we can allocate a new SCB.
*/
diff --git a/drivers/scsi/aic7xxx/aic7xxx_inline.h
b/drivers/scsi/aic7xxx/aic7xxx_inline.h
index 0b57b78..cef8d98 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_inline.h
+++ b/drivers/scsi/aic7xxx/aic7xxx_inline.h
@@ -77,10 +77,6 @@ uint32_t
ahc_inl(struct ahc_softc *ahc, u_int port);
void ahc_outl(struct ahc_softc *ahc, u_int port,
uint32_t value);
-uint64_t
- ahc_inq(struct ahc_softc *ahc, u_int port);
-void ahc_outq(struct ahc_softc *ahc, u_int port,
-uint64_t value);
struct scb*
ahc_get_scb(struct ahc_softc *ahc);
void ahc_free_scb(struct ahc_softc *ahc, struct scb *scb);
--
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] ti-soc-thermal: implement eocz bit to make driver useful on omap3
Hi!
> > When periodic mode is not enabled, it is neccessary to force reads.
> >
> > Signed-off-by: Pavel Machek
> >
> > --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> > +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> > @@ -43,6 +43,8 @@
> >
> > #include "ti-bandgap.h"
> >
> > +static int ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id);
> > +
> > /*** Helper functions to access registers and their bitfields ***/
> >
> > /**
> > @@ -852,14 +831,20 @@ int ti_bandgap_read_temperature(struct ti_bandgap
> > *bgp, int id,
> > if (ret)
> > return ret;
> >
> > + if (!TI_BANDGAP_HAS(bgp, MODE_CONFIG)) {
> > + ret = ti_bandgap_force_single_read(bgp, id);
>
> not sure MODE_CONFIG is sufficient condition for single read on all OMAP
> versions.
Ok, what do you suggest? AFAICT, without MODE_CONFIG, continuous ADC
mode is not available, so we have to force it periodically, so this
should be correct.
> > + if (ret)
> > + return ret;
> > + }
> > +
> > spin_lock(>lock);
> > temp = ti_bandgap_read_temp(bgp, id);
> > spin_unlock(>lock);
> >
> > - ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, );
> > + ret = ti_bandgap_adc_to_mcelsius(bgp, temp, );
>
> this one should be part of your clean up patch
Ok, can you apply the cleanup patch and I'll prepare one on the top of
it?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
2015-01-04 0:34 GMT+09:00 Nishanth Menon : > On 15:40-20150103, Tomasz Figa wrote: >> Hi Nishanth, >> >> 2015-01-03 2:43 GMT+09:00 Nishanth Menon : >> > AM437x generation of processors support programming the PL310 L2Cache >> > controller's address filter start and end registers using a secure >> > montior service. >> >> typo: s/montior/monitor/ >> >> [snip] > > Uggh.. yes indeed. I will post a v3 updating the comments. If the > following is ok. >> >> > + base = omap4_get_l2cache_base(); >> > + filter_start = (reg == L310_ADDR_FILTER_START) ? val : >> > + readl_relaxed(base + >> > L310_ADDR_FILTER_START); >> > + filter_end = (reg == L310_ADDR_FILTER_END) ? val : >> > + readl_relaxed(base + L310_ADDR_FILTER_END); >> > + omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start, >> > + filter_end); >> > + return; >> >> I don't have any significant comments about this patch in particular, >> but just noticed that you need to do read-backs here (and the typo >> thanks to the spell checker of my mailing app). Maybe you should >> consider switching to the .configure() API I introduced in my series? >> This would let you get rid of the hardcoded static mapping. > > Yeah, I have two choices there.. Either I provide the fundamental > write function for the generic l2c code to use OR I provide a > duplicate of resultant l2c_configure(aux write) + l2c310_configure. > > To allow for reuse of improvements or anything like errata > implementations in the future, OMAP L2C implementation has chosen to provide > the > low level code and allow the higherlevel configure/write/whatever of the > future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is > not too complicated enough to warrant a replication of l2c310_configure. > > So, I prefer the current implementation than providing a .configure > handler for outer_cache.configure from SoC level. > > Let me know if anyone has a strong objection to this. Well, what l2c310_configure() does after my series is just writing the registers. If they cannot be written normally (without some tricks such as reading back other registers) then IMHO a separate function should be provided. This is becomes possible after patch 3/8 (ARM: l2c: Add interface to ask hypervisor to configure L2C) and what is used on Exynos which also updates multiple registers in single SMC calls. You can find an example of use in patch 6/8 (ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310). What's even more interesting is that approaches similar to the one currently used on OMAP had been NAKed, when proposed for Exynos and this is why we have the solution proposed by my patches. Note that .write_sec() callback is still used for L2X0_CTRL and L2X0_DEBUG_CTRL registers, because there might be a need to write them separately (e.g. to disable the controller and to perform debug operations/workarounds when the controller is already enabled). Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: gdm724x: fix coding style issues
Signed-off-by: Ning Zhou
---
drivers/staging/gdm724x/gdm_lte.c | 3 ++-
drivers/staging/gdm724x/gdm_mux.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/gdm724x/gdm_lte.c
b/drivers/staging/gdm724x/gdm_lte.c
index 73eede1..7c4a77b 100644
--- a/drivers/staging/gdm724x/gdm_lte.c
+++ b/drivers/staging/gdm724x/gdm_lte.c
@@ -281,7 +281,8 @@ static int gdm_lte_emulate_ndp(struct sk_buff *skb_in, u32
nic_type)
icmp6_out.icmp6_type = NDISC_NEIGHBOUR_ADVERTISEMENT;
icmp6_out.icmp6_code = 0;
icmp6_out.icmp6_cksum = 0;
- icmp6_out.icmp6_dataun.un_data32[0] = htonl(0x6000); /*
R=0, S=1, O=1 */
+ /* R=0, S=1, O=1 */
+ icmp6_out.icmp6_dataun.un_data32[0] = htonl(0x6000);
ns = (struct neighbour_solicitation *)
(skb_in->data + mac_header_len +
diff --git a/drivers/staging/gdm724x/gdm_mux.c
b/drivers/staging/gdm724x/gdm_mux.c
index b5b063a..d1ab996 100644
--- a/drivers/staging/gdm724x/gdm_mux.c
+++ b/drivers/staging/gdm724x/gdm_mux.c
@@ -220,7 +220,7 @@ static int up_to_host(struct mux_rx *r)
static void do_rx(struct work_struct *work)
{
struct mux_dev *mux_dev =
- container_of(work, struct mux_dev , work_rx.work);
+ container_of(work, struct mux_dev, work_rx.work);
struct mux_rx *r;
struct rx_cxt *rx = (struct rx_cxt *)_dev->rx;
unsigned long flags;
--
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/1 linux-next] mm,compaction: move suitable_migration_target() under CONFIG_COMPACTION
suitable_migration_target() is only used by isolate_freepages()
Define it under CONFIG_COMPACTION || CONFIG_CMA is not needed.
Fix the following warning:
mm/compaction.c:311:13: warning: 'suitable_migration_target' defined
but not used [-Wunused-function]
Signed-off-by: Fabian Frederick
---
mm/compaction.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 546e571..38b151c 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -307,28 +307,6 @@ static inline bool compact_should_abort(struct
compact_control *cc)
return false;
}
-/* Returns true if the page is within a block suitable for migration to */
-static bool suitable_migration_target(struct page *page)
-{
- /* If the page is a large free page, then disallow migration */
- if (PageBuddy(page)) {
- /*
-* We are checking page_order without zone->lock taken. But
-* the only small danger is that we skip a potentially suitable
-* pageblock, so it's not worth to check order for valid range.
-*/
- if (page_order_unsafe(page) >= pageblock_order)
- return false;
- }
-
- /* If the block is MIGRATE_MOVABLE or MIGRATE_CMA, allow migration */
- if (migrate_async_suitable(get_pageblock_migratetype(page)))
- return true;
-
- /* Otherwise skip the block */
- return false;
-}
-
/*
* Isolate free pages onto a private freelist. If @strict is true, will abort
* returning 0 on any invalid PFNs or non-free pages inside of the pageblock
@@ -802,6 +780,28 @@ isolate_migratepages_range(struct compact_control *cc,
unsigned long start_pfn,
#endif /* CONFIG_COMPACTION || CONFIG_CMA */
#ifdef CONFIG_COMPACTION
+/* Returns true if the page is within a block suitable for migration to */
+static bool suitable_migration_target(struct page *page)
+{
+ /* If the page is a large free page, then disallow migration */
+ if (PageBuddy(page)) {
+ /*
+* We are checking page_order without zone->lock taken. But
+* the only small danger is that we skip a potentially suitable
+* pageblock, so it's not worth to check order for valid range.
+*/
+ if (page_order_unsafe(page) >= pageblock_order)
+ return false;
+ }
+
+ /* If the block is MIGRATE_MOVABLE or MIGRATE_CMA, allow migration */
+ if (migrate_async_suitable(get_pageblock_migratetype(page)))
+ return true;
+
+ /* Otherwise skip the block */
+ return false;
+}
+
/*
* Based on information in the current compact_control, find blocks
* suitable for isolating free pages from and then isolate them.
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH RESEND] mm: vmalloc: remove ioremap align constraint
Hi Arnd,
First, some background information. We originally encountered high fragmentation
issue in vmalloc area:
1. Total size of vmalloc area was 400 MB.
2. 200 MB of vmalloc area was consumed by ioremaps of various sizes.
3. Largest contiguous chunk of vmalloc area was 12 MB.
4. ioremap of 10 MB failed due to 8 MB alignment requirement.
It was decided to further increase the size of vmalloc area to resolve the above
issue. And I don't like that solution because it decreases the amount of lowmem.
Now let's see how ioremap uses supersections. Judging from current
implementation
of __arm_ioremap_pfn_caller:
#if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE)
if (pfn >= 0x10 && !((paddr | size | addr) &
~SUPERSECTION_MASK)) {
remap_area_supersections();
} else if (!((paddr | size | addr) & ~PMD_MASK)) {
remap_area_sections();
} else
#endif
err = ioremap_page_range();
supersections and sections mappings are used only in !SMP && !LPAE case.
Otherwise, mapping is created using the usual 4K pages (and we are using SMP).
The suggested patch removes alignment requirements for ioremap but it means that
sections will not be used in !SMP case. So another solution is required.
__get_vm_area_node has align parameter, maybe it can be used to specify the
required alignment of ioremap operation? Because I find current generic fls
algorithm to be very restrictive in cases when it's not necessary to use such
a big alignment.
On Tue, 23 Dec 2014 21:58:49 +0100
Arnd Bergmann wrote:
> On Tuesday 23 December 2014 13:00:13 Dmitry Safonov wrote:
> > ioremap uses __get_vm_area_node which sets alignment to fls of requested
> > size.
> > I couldn't find any reason for such big align. Does it decrease TLB misses?
> > I tested it on custom ARM board with 200+ Mb of ioremap and it works.
> > What am I missing?
>
> The alignment was originally introduced in this commit:
>
> commit ff0daca525dde796382b9ccd563f169df2571211
> Author: Russell King
> Date: Thu Jun 29 20:17:15 2006 +0100
>
> [ARM] Add section support to ioremap
>
> Allow section mappings to be setup using ioremap() and torn down
> with iounmap(). This requires additional support in the MM
> context switch to ensure that mappings are properly synchronised
> when mapped in.
>
> Based an original implementation by Deepak Saxena, reworked and
> ARMv6 support added by rmk.
>
> Signed-off-by: Russell King
>
> and then later extended to 16MB supersection mappings, which indeed
> is used to reduce TLB pressure.
>
> I don't see any downsides to it, why change it?
>
> Arnd
--
Sergey Dyasly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] power: avs: smartreflex: Remove unused function
Remove the function sr_configure_minmax() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/power/avs/smartreflex.c | 86 -
include/linux/power/smartreflex.h |1 -
2 files changed, 87 deletions(-)
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index db9973b..62b8351 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -460,92 +460,6 @@ int sr_disable_errgen(struct omap_sr *sr)
}
/**
- * sr_configure_minmax() - Configures the SmartReflex to perform AVS using the
- * minmaxavg module.
- * @sr:SR module to be configured.
- *
- * This API is to be called from the smartreflex class driver to
- * configure the minmaxavg module inside the smartreflex module.
- * SR settings if using the ERROR module inside Smartreflex.
- * SR CLASS 3 by default uses only the ERROR module where as
- * SR CLASS 2 can choose between ERROR module and MINMAXAVG
- * module. Returns 0 on success and error value in case of failure.
- */
-int sr_configure_minmax(struct omap_sr *sr)
-{
- u32 sr_config, sr_avgwt;
- u32 senp_en = 0, senn_en = 0;
- u8 senp_shift, senn_shift;
-
- if (!sr) {
- pr_warn("%s: NULL omap_sr from %pF\n", __func__,
- (void *)_RET_IP_);
- return -EINVAL;
- }
-
- if (!sr->clk_length)
- sr_set_clk_length(sr);
-
- senp_en = sr->senp_mod;
- senn_en = sr->senn_mod;
-
- sr_config = (sr->clk_length << SRCONFIG_SRCLKLENGTH_SHIFT) |
- SRCONFIG_SENENABLE |
- (sr->accum_data << SRCONFIG_ACCUMDATA_SHIFT);
-
- switch (sr->ip_type) {
- case SR_TYPE_V1:
- sr_config |= SRCONFIG_DELAYCTRL;
- senn_shift = SRCONFIG_SENNENABLE_V1_SHIFT;
- senp_shift = SRCONFIG_SENPENABLE_V1_SHIFT;
- break;
- case SR_TYPE_V2:
- senn_shift = SRCONFIG_SENNENABLE_V2_SHIFT;
- senp_shift = SRCONFIG_SENPENABLE_V2_SHIFT;
- break;
- default:
- dev_err(>pdev->dev, "%s: Trying to Configure smartreflex"
- "module without specifying the ip\n", __func__);
- return -EINVAL;
- }
-
- sr_config |= ((senn_en << senn_shift) | (senp_en << senp_shift));
- sr_write_reg(sr, SRCONFIG, sr_config);
- sr_avgwt = (sr->senp_avgweight << AVGWEIGHT_SENPAVGWEIGHT_SHIFT) |
- (sr->senn_avgweight << AVGWEIGHT_SENNAVGWEIGHT_SHIFT);
- sr_write_reg(sr, AVGWEIGHT, sr_avgwt);
-
- /*
-* Enabling the interrupts if MINMAXAVG module is used.
-* TODO: check if all the interrupts are mandatory
-*/
- switch (sr->ip_type) {
- case SR_TYPE_V1:
- sr_modify_reg(sr, ERRCONFIG_V1,
- (ERRCONFIG_MCUACCUMINTEN | ERRCONFIG_MCUVALIDINTEN |
- ERRCONFIG_MCUBOUNDINTEN),
- (ERRCONFIG_MCUACCUMINTEN | ERRCONFIG_MCUACCUMINTST |
-ERRCONFIG_MCUVALIDINTEN | ERRCONFIG_MCUVALIDINTST |
-ERRCONFIG_MCUBOUNDINTEN | ERRCONFIG_MCUBOUNDINTST));
- break;
- case SR_TYPE_V2:
- sr_write_reg(sr, IRQSTATUS,
- IRQSTATUS_MCUACCUMINT | IRQSTATUS_MCVALIDINT |
- IRQSTATUS_MCBOUNDSINT | IRQSTATUS_MCUDISABLEACKINT);
- sr_write_reg(sr, IRQENABLE_SET,
- IRQENABLE_MCUACCUMINT | IRQENABLE_MCUVALIDINT |
- IRQENABLE_MCUBOUNDSINT | IRQENABLE_MCUDISABLEACKINT);
- break;
- default:
- dev_err(>pdev->dev, "%s: Trying to Configure smartreflex"
- "module without specifying the ip\n", __func__);
- return -EINVAL;
- }
-
- return 0;
-}
-
-/**
* sr_enable() - Enables the smartreflex module.
* @sr:pointer to which the SR module to be configured belongs
to.
* @volt: The voltage at which the Voltage domain associated with
diff --git a/include/linux/power/smartreflex.h
b/include/linux/power/smartreflex.h
index d8b187c3..ffd31af 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -303,7 +303,6 @@ int sr_enable(struct omap_sr *sr, unsigned long volt);
void sr_disable(struct omap_sr *sr);
int sr_configure_errgen(struct omap_sr *sr);
int sr_disable_errgen(struct omap_sr *sr);
-int sr_configure_minmax(struct omap_sr *sr);
/* API to register the smartreflex class driver with the smartreflex driver */
int sr_register_class(struct omap_sr_class_data *class_data);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH] net: wireless: b43legacy: radio.c: Remove unused function
2015-01-03 15:51 GMT+01:00 Sedat Dilek : > On Sat, Jan 3, 2015 at 3:45 PM, Rickard Strandqvist > wrote: > [ ... ] >>> > I just got one more complaining about my subject-line in "net: wireless: " >>> > I use some sed call for this, so it's easy to fix. I will now remove that >>> > part hereinafter. >>> > I check in Documentation/ but did not find any clear info for this. >>> > >>> >>> The easiest way to make (sub)maintainers happy is to check the git-log... >>> >>> $ git log --oneline /path/to/file >>> >>> ...and look how other contributors labeled their patches. >>> >>> [1] is the 1st address to look at on how to submit patches to Linux-kernel. >>> To promote the good work of Greg, see [2,3] for a video and tutorial >>> on that topic, too. >>> >>> - Sedat - >>> >>> [1] >>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches >>> [2] https://www.youtube.com/watch?v=XXix80GCvpo >>> [3] https://github.com/gregkh/kernel-tutorial >> >> >> >> Hi Sedat >> >> Thanks for the tip :) >> >> To bad with the audio in the video thow. Have read SubmittingPatches before. >> > > AFAICS there is another (earlier) video "Write and Submit your first > Linux kernel Patch" from FOSDEM 2010. > > For German readers I can recommend the book from [2] (no I get no > money for promotion). > > - Sedat - > > [1] https://www.youtube.com/watch?v=LLBrBBImJt4 > [2] http://www.opensourcepress.de/de/produkte/Git/33227/978-3-95539-119-5- > >> >> But I have now added a line in my script that does a: >> >> git log -10 --oneline >> >> So I can at least see the other subjekt lines, and make adjustments if >> necessary. >> >> >> >> Kind regards >> Rickard Strandqvist Hi Good video! Wish I had seen this a year ago. Sorry, no German for me :) Kind regards Rickard Strandqvist -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.\
On 15:42-20150103, Tomasz Figa wrote: > Indeed, as I figured out in the original thread about this issue, > additional patch fixing code unaffected by my series (besides changing > the condition which triggers calling it) is necessary. Namely, the > affected 4 registers need to be written using the write_sec wrapper, > instead of using writel*() directly. > Agreed. Would you like to post a patch (independent) of your series to address this - sounds like a fix that should go in independent of your original series. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
On 15:40-20150103, Tomasz Figa wrote: > Hi Nishanth, > > 2015-01-03 2:43 GMT+09:00 Nishanth Menon : > > AM437x generation of processors support programming the PL310 L2Cache > > controller's address filter start and end registers using a secure > > montior service. > > typo: s/montior/monitor/ > > [snip] Uggh.. yes indeed. I will post a v3 updating the comments. If the following is ok. > > > + base = omap4_get_l2cache_base(); > > + filter_start = (reg == L310_ADDR_FILTER_START) ? val : > > + readl_relaxed(base + L310_ADDR_FILTER_START); > > + filter_end = (reg == L310_ADDR_FILTER_END) ? val : > > + readl_relaxed(base + L310_ADDR_FILTER_END); > > + omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start, > > + filter_end); > > + return; > > I don't have any significant comments about this patch in particular, > but just noticed that you need to do read-backs here (and the typo > thanks to the spell checker of my mailing app). Maybe you should > consider switching to the .configure() API I introduced in my series? > This would let you get rid of the hardcoded static mapping. Yeah, I have two choices there.. Either I provide the fundamental write function for the generic l2c code to use OR I provide a duplicate of resultant l2c_configure(aux write) + l2c310_configure. To allow for reuse of improvements or anything like errata implementations in the future, OMAP L2C implementation has chosen to provide the low level code and allow the higherlevel configure/write/whatever of the future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is not too complicated enough to warrant a replication of l2c310_configure. So, I prefer the current implementation than providing a .configure handler for outer_cache.configure from SoC level. Let me know if anyone has a strong objection to this. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PCI/sysfs: off by two and memory corruption in driver_override parameter
On Thu, Jan 1, 2015 at 5:27 PM, Sasha Levin wrote:
> There are two different issues fixed here:
>
> - On nun-NULL terminated input a random byte of memory would get flipped
> from '\n' to '\0'.
> - When printing the driver_override parameter when it is 4095 and 4094 bytes
> long the printing code would access invalid memory.
Thanks, Sasha.
Can you please:
- Split these two fixes into two separate patches
- Look up the commit that introduced this code
- CC the author
- Add "Fixes: " lines
- Add stable tags for the relevant kernels
Bjorn
> Signed-off-by: Sasha Levin
> ---
> drivers/pci/pci-sysfs.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index aa012fb..be6b2b1 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -521,17 +521,17 @@ static ssize_t driver_override_store(struct device *dev,
> struct pci_dev *pdev = to_pci_dev(dev);
> char *driver_override, *old = pdev->driver_override, *cp;
>
> - if (count > PATH_MAX)
> + /* We need to keep extra room for a newline */
> + if (count >= (PATH_MAX - 1))
> return -EINVAL;
>
> driver_override = kstrndup(buf, count, GFP_KERNEL);
> if (!driver_override)
> return -ENOMEM;
>
> - cp = strchr(driver_override, '\n');
> - if (cp)
> - *cp = '\0';
> -
> + driver_override[count] = '\0';
> + if (driver_override[count - 1] == '\n')
> + driver_override[count - 1] = 0;
> if (strlen(driver_override)) {
> pdev->driver_override = driver_override;
> } else {
> --
> 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: perf-probe crash in dwarf_getcfi_elf
Hi Mark, On Thu, Jan 1, 2015 at 4:42 AM, Mark Wielaard wrote: > On Tue, Dec 30, 2014 at 06:05:33PM +0900, Namhyung Kim wrote: >> And I found a related commit (5704c8c4fa71 "getcfi_scn_eh_frame: Don't >> crash and burn when .eh_frame bits aren't there.") in elfutils that >> can lead to a unexpected crash like this. To safely use the function, >> it needs to check the .eh_frame section is a PROGBITS type. > > Sorry about that bug. It was fixed in elfutils 0.156, released July 2013. > Latest elfutils release is 0.161. > > Checking .eh_frame is SHT_PROGBITS (and not SHT_NOBITS) looks like the > correct workaround if you have to deal with older elfutils releases. Thanks for confirming this. > > Note that dwarf_getcfi_elf gets the CFI information from the .eh_frame > section associated with the ELF file underlying the Dwarf dbg and needs > to be released with a call to dwarf_cfi_end (). dwarf_getcfi () gets the > CFI information from the .debug_frame section data of the Dwarf dbg > and gets automatically releassed when dwarf_end () is called (you should > not call dwarf_cfi_end () on the result). Ah, it's good to know. I have to check the code.. > > If the Dwarf dbg handle is associated with a separate debuginfo file, > then the .eh_frame section data will not be available (has SHT_NOBITS) > and you can get the .eh_frame section (and call dwarf_getcfi_elf ()) on > the original ELF file from which the Dwarf debuginfo file was split off. > > In your patch you call dwarf_getcfi () as backup to get some CFI > information when you cannot call dwarf_getcfi_elf (). In general it > might make sense to also do this when dwarf_getcfi_elf fails. Or try > to get the CFI through both .eh_frame (from the executable ELF file) > with dwarf_getcfi_elf () and .debug_frame (from the Dwarf dbg file) > with dwarf_getcfi () and try to match an address in both tables > if one or the other fails. Thanks for your advice, I'll make a follow-up patch to address your comments. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Drivers: isdn: gigaset: checkpatch cleanup
[I only just noticed that my first reply got terribly mangled by my
mailer, so here it is again, hopefully more readable this time.]
Hello Bas,
I have several objections to your patch.
Am 31.12.2014 um 18:34 schrieb Bas Peters:
> I have not been able to test the code as I do not have access to the
> hardware but since no new features were really added I don't think that
> should pose a problem.
It's always problematic to change code you cannot test.
At the very least, if you do coding style cleanups you should test
whether the result still compiles and generates the same code as before.
> --- a/drivers/isdn/gigaset/bas-gigaset.c
> +++ b/drivers/isdn/gigaset/bas-gigaset.c
> @@ -261,11 +261,12 @@ static inline void dump_urb(enum debuglevel level,
> const char *tag,
> {
> #ifdef CONFIG_GIGASET_DEBUG
> int i;
> +
> gig_dbg(level, "%s urb(0x%08lx)->{", tag, (unsigned long) urb);
> if (urb) {
> gig_dbg(level,
> - " dev=0x%08lx, pipe=%s:EP%d/DV%d:%s, "
> - "hcpriv=0x%08lx, transfer_flags=0x%x,",
> + " dev=0x%08lx, pipe=%s:EP%d/DV%d:%s,
> + hcpriv=0x%08lx, transfer_flags=0x%x,",
This is syntactically wrong and won't compile. You cannot have an
unescaped newline inside a string literal. (Applies to two later
chunks, too.)
> @@ -566,8 +566,8 @@ static int atread_submit(struct cardstate *cs, int
> timeout)
>
> if (basstate & BS_SUSPEND) {
> dev_notice(cs->dev,
> -"HD_READ_ATMESSAGE not submitted, "
> -"suspend in progress\n");
> +"HD_READ_ATMESSAGE not submitted,\
> +suspend in progress\n");
This makes the message less readable by inserting lots of whitespace
after the comma. (Applies to five later chunks, too.)
> @@ -2312,13 +2312,13 @@ static int gigaset_probe(struct usb_interface
> *interface,
> /* Reject application specific interfaces
>*/
> if (hostif->desc.bInterfaceClass != 255) {
> - dev_warn(>dev, "%s: bInterfaceClass == %d\n",
> + dev_warn(>dev, "%s: bInterfaceClass == %d\n",\
>__func__, hostif->desc.bInterfaceClass);
> return -ENODEV;
> }
>
> dev_info(>dev,
> - "%s: Device matched (Vendor: 0x%x, Product: 0x%x)\n",
> + "%s: Device matched (Vendor: 0x%x, Product: 0x%x)\n",\
>__func__, le16_to_cpu(udev->descriptor.idVendor),
>le16_to_cpu(udev->descriptor.idProduct));
This looks strange, and not like correct coding style. Why would you
want to escape the end of line after a function argument?
> --- a/drivers/isdn/gigaset/capi.c
> +++ b/drivers/isdn/gigaset/capi.c
> @@ -1370,7 +1373,7 @@ static void do_connect_req(struct gigaset_capi_ctr *iif,
> cmsg->adr.adrPLCI |= (bcs->channel + 1) << 8;
>
> /* build command table */
> - commands = kzalloc(AT_NUM * (sizeof *commands), GFP_KERNEL);
> + commands = kzalloc(AT_NUM * (sizeof(*commands)), GFP_KERNEL);
Extra pair of parentheses around sizeof(*commands) is unnecessary.
(Applies to one later chunk, too.)
> --- a/drivers/isdn/gigaset/common.c
> +++ b/drivers/isdn/gigaset/common.c
> @@ -53,7 +53,7 @@ void gigaset_dbg_buffer(enum debuglevel level, const
> unsigned char *msg,
> {
> unsigned char outbuf[80];
> unsigned char c;
> - size_t space = sizeof outbuf - 1;
> + size_t space = sizeof(outbuf - 1);
This is wrong. The sizeof operator must be applied to the array
variable outbuf, not to the expression (outbuf - 1).
> --- a/drivers/isdn/gigaset/ev-layer.c
> +++ b/drivers/isdn/gigaset/ev-layer.c
> @@ -1083,7 +1079,7 @@ static void do_action(int action, struct cardstate *cs,
>
> int channel;
>
> - unsigned char *s, *e;
> + unsigned char *s;
> int i;
> unsigned long val;
>
> @@ -1355,8 +1351,20 @@ static void do_action(int action, struct cardstate *cs,
> }
>
> for (i = 0; i < 4; ++i) {
> - val = simple_strtoul(s, (char **) , 10);
> - if (val > INT_MAX || e == s)
> + unsigned long *e;
> +
> + val = kstrtoul(s, 10, e);
> + if (val == -EINVAL) {
> + dev_err(cs->dev, "Parsing error on converting
> string to\
> + unsigned long\n");
> + break;
> + }
> + if (val == -ERANGE) {
> + dev_err(cs->dev, "Overflow error converting
> string to\
> + unsigned long\n");
> + break;
> + }
> + if (val > INT_MAX || *e == s)
> break;
> if (i == 3) {
>
Re: [PATCH 6/7] perf tools: Append callchains only when requested
Hi Arnaldo, On Sat, Jan 3, 2015 at 11:25 AM, Arnaldo Carvalho de Melo wrote: > Em Mon, Dec 22, 2014 at 01:44:14PM +0900, Namhyung Kim escreveu: >> The perf report --children can be called with callchain disabled so no >> need to append callchains. Actually the root of callchain tree is not >> initialized properly in this case. > > Hi Namhyung, > > I should have caught this using 'perf test', but it slipped > thru, please try running 'perf test cumulation', I noticed that it fails > and that if I revert this changeset it works again, can you please > check? This change should not affect the test result, but I guess the test somehow relied on the undefined behavior. Actually I posted a patch to fix this problem. So please take a look at the link below: https://lkml.org/lkml/2014/12/22/561 Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: frequent lockups in 3.18rc4
On 01/02/2015 07:27 PM, John Stultz wrote: > On Fri, Dec 26, 2014 at 12:57 PM, Linus Torvalds > wrote: >> > On Fri, Dec 26, 2014 at 10:12 AM, Dave Jones >> > wrote: >>> >> On Fri, Dec 26, 2014 at 11:34:10AM -0500, Dave Jones wrote: >>> >> >>> >> > One thing I think I'll try is to try and narrow down which >>> >> > syscalls are triggering those "Clocksource hpet had cycles off" >>> >> > messages. I'm still unclear on exactly what is doing >>> >> > the stomping on the hpet. >>> >> >>> >> First I ran trinity with "-g vm" which limits it to use just >>> >> a subset of syscalls, specifically VM related ones. >>> >> That triggered the messages. Further experiments revealed: >> > >> > So I can trigger the false positives with my original patch quite >> > easily by just putting my box under some load. My numbers are nowhere >> > near as bad as yours, but then, I didn't put it under as much load >> > anyway. Just a regular "make -j64" of the kernel. >> > >> > I suspect your false positives are bigger partly because of the load, >> > but mostly because you presumably have preemption enabled too. I don't >> > do preemption in my normal kernels, and that limits the damage of the >> > race a bit. >> > >> > I have a newer version of the patch that gets rid of the false >> > positives with some ordering rules instead, and just for you I hacked >> > it up to say where the problem happens too, but it's likely too late. >> > >> > The fact that the original racy patch seems to make a difference for >> > you does say that yes, we seem to be zeroing in on the right area >> > here, but I'm not seeing what's wrong. I was hoping for big jumps from >> > your HPET, since your "TSC unstable" messages do kind of imply that >> > such really big jumps can happen. >> > >> > I'm attaching my updated hacky patch, although I assume it's much too >> > late for that machine. Don't look too closely at the backtrace >> > generation part, that's just a quick hack, and only works with frame >> > pointers enabled anyway. >> > >> > So I'm still a bit unhappy about not figuring out *what* is wrong. And >> > I'd still like the dmidecode from that machine, just for posterity. In >> > case we can figure out some pattern. >> > >> > So right now I can imagine several reasons: >> > >> > - actual hardware bug. >> > >> >This is *really* unlikely, though. It should hit everybody. The >> > HPET is in the core intel chipset, we're not talking random unusual >> > hardware by fly-by-night vendors here. >> > >> > - some SMM/BIOS "power management" feature. >> > >> >We've seen this before, where the SMM saves/restores the TSC on >> > entry/exit in order to hide itself from the system. I could imagine >> > similar code for the HPET counter. SMM writers use some bad drugs to >> > dull their pain. >> > >> >And with the HPET counter, since it's not even per-CPU, the "save >> > and restore HPET" will actually show up as "HPET went backwards" to >> > the other non-SMM CPU's if it happens >> > >> > - a bug in our own clocksource handling. >> > >> >I'm not seeing it. But maybe my patch hides it for some magical reason. > So I sent out a first step validation check to warn us if we end up > with idle periods that are larger then we expect. > > It doesn't yet cap the timekeeping_get_ns() output (like you're patch > effectively does), but it would be easy to do that in a following > patch. > > I did notice while testing this that the max_idle_ns (max idle time we > report to the scheduler) for the hpet is only ~16sec, and we'll > overflow after just ~21seconds. This second number maps closely to the > 22 second stalls seen in the nmi watchdog reports which seems > interesting, but I also realize that qemu uses a 100MHz hpet, where as > real hardware is likely to be a bit slower, so maybe that's just > chance.. > > I'd be interested if folks seeing anything similar to Dave would give > my patch a shot. I ran it overnight, but I didn't see any of the new warnings in the logs. 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/
[PATCH] Revert "ipw2200: select CFG80211_WEXT"
This reverts commit 60220f41775e634258efd1b54c6fa81ce706.
The raison d'être of commit 60220f41 ("ipw2200: select
CFG80211_WEXT") was reverted in commit 2d36e008739e ("Revert "cfg80211:
make WEXT compatibility unselectable""). So revert this commit too.
Signed-off-by: Paul Bolle
---
drivers/net/wireless/ipw2x00/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/Kconfig
b/drivers/net/wireless/ipw2x00/Kconfig
index 21de4fe6cf2d..91c0cb3c368e 100644
--- a/drivers/net/wireless/ipw2x00/Kconfig
+++ b/drivers/net/wireless/ipw2x00/Kconfig
@@ -65,8 +65,7 @@ config IPW2100_DEBUG
config IPW2200
tristate "Intel PRO/Wireless 2200BG and 2915ABG Network Connection"
- depends on PCI && CFG80211
- select CFG80211_WEXT
+ depends on PCI && CFG80211 && CFG80211_WEXT
select WIRELESS_EXT
select WEXT_SPY
select WEXT_PRIV
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] next: microblaze: Fix build failure
Microblaze build in linux-next fails with
arch/microblaze/kernel/timer.c:224:2: error:
implicit declaration of function 'timecounter_init'
Caused by missing include file in microblaze timer code.
Fixes: 74d23cc704d1 ("time: move the timecounter/cyclecounter code into its own
file")
Cc: Richard Cochran
Cc: Jeff Kirsher
Signed-off-by: Guenter Roeck
---
arch/microblaze/kernel/timer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/microblaze/kernel/timer.c b/arch/microblaze/kernel/timer.c
index dd96f0e..c897745 100644
--- a/arch/microblaze/kernel/timer.c
+++ b/arch/microblaze/kernel/timer.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
static void __iomem *timer_baseaddr;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
