Re: [PATCH 0/6] x86: reduce paravirtualized spinlock overhead
On 04/30/2015 06:39 PM, Jeremy Fitzhardinge wrote: On 04/30/2015 03:53 AM, Juergen Gross wrote: Paravirtualized spinlocks produce some overhead even if the kernel is running on bare metal. The main reason are the more complex locking and unlocking functions. Especially unlocking is no longer just one instruction but so complex that it is no longer inlined. This patch series addresses this issue by adding two more pvops functions to reduce the size of the inlined spinlock functions. When running on bare metal unlocking is again basically one instruction. Out of curiosity, is there a measurable difference? I did a small measurement of the pure locking functions on bare metal without and with my patches. spin_lock() for the first time (lock and code not in cache) dropped from about 600 to 500 cycles. spin_unlock() for first time dropped from 145 to 87 cycles. spin_lock() in a loop dropped from 48 to 45 cycles. spin_unlock() in the same loop dropped from 24 to 22 cycles. Juergen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] dmaengine: xgene-dma: Fix sparse wannings warnings
On Thu, Apr 23, 2015 at 05:26:45PM +0530, Rameshwar Prasad Sahu wrote:
Suject line should mention the fixes you are doing and not tool!
> v5 changes:
> * Re-pull v3 changes that I missed in v4
>
> v4 changes:
> * Re-generate patch on top of latest for-linux git
>
> v3 changes:
> * Minor changes in length setting in DMA descriptor
>
> v2 changes:
> * Code cleanup
> * Changed way of setting DMA descriptors for big-endian
This is *not* supposed to be part of changelog!
You can add this after the S-O-B line!!
>
> This patch fixes compilation sparse warnings like incorrect type in assignment
> (different base types), cast to restricted __le64, symbol
> '__UNIQUE_ID_author__COUNTER__' has multiple initializers etc.
>
> This patch is based on slave-dma / for-linus branch.
> (commit: 11ebe4c067c7f95adff73594cb5c23f7a5c6d69e
> dmaengine: fix platform_no_drv_owner.cocci warnings
this too :(
>
> Reported-by: kbuild test robot
> Signed-off-by: Rameshwar Prasad Sahu
>
> MODULE_DESCRIPTION("APM X-Gene SoC DMA driver");
> MODULE_AUTHOR("Rameshwar Prasad Sahu ");
> -MODULE_AUTHOR("Loc Ho ");
Pls drop this
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tick-broadcast: Fix the printing of broadcast masks
Ping.
Any comments on this patch ?
Regards
Preeti U Murthy
On 04/28/2015 02:15 PM, Preeti U Murthy wrote:
> Today the number of bits of the broadcast masks that is output into
> /proc/timer_list is sizeof(unsigned long). This means that on machines
> with larger number of CPUs, the bitmasks of CPUs beyond this range do
> not appear.
>
> Fix this by using bitmap printing through "%*pb" instead, so as to
> output the broadcast masks for the range of nr_cpu_ids into
> /proc/timer_list.
>
> Signed-off-by: Preeti U Murthy
> ---
>
> kernel/time/timer_list.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
> index c82b03c..1afc726 100644
> --- a/kernel/time/timer_list.c
> +++ b/kernel/time/timer_list.c
> @@ -269,11 +269,11 @@ static void timer_list_show_tickdevices_header(struct
> seq_file *m)
> {
> #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
> print_tickdevice(m, tick_get_broadcast_device(), -1);
> - SEQ_printf(m, "tick_broadcast_mask: %08lx\n",
> -cpumask_bits(tick_get_broadcast_mask())[0]);
> + SEQ_printf(m, "tick_broadcast_mask: %*pb\n",
> +cpumask_pr_args(tick_get_broadcast_mask()));
> #ifdef CONFIG_TICK_ONESHOT
> - SEQ_printf(m, "tick_broadcast_oneshot_mask: %08lx\n",
> -cpumask_bits(tick_get_broadcast_oneshot_mask())[0]);
> + SEQ_printf(m, "tick_broadcast_oneshot_mask: %*pb\n",
> +cpumask_pr_args(tick_get_broadcast_oneshot_mask()));
> #endif
> SEQ_printf(m, "\n");
> #endif
>
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] md/raid5: init batch_xxx for new sh at resize_stripes
This is to fix a kernel NULL dereference oops introduced by commit
59fc630b("RAID5: batch adjacent full stripe write"), which introduced
several batch_xxx fields, and did initiation for them at grow_one_stripes(),
but forgot to do same at resize_stripes().
This oops can be easily triggered by following steps:
__create RAID5 /dev/md0
__grow /dev/md0
mdadm --wait /dev/md0
dd if=/dev/zero of=/dev/md0
Here is the detailed oops log:
[ 32.384499] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 32.385366] IP: [] add_stripe_bio+0x48d/0x544
[ 32.385955] PGD 373f3067 PUD 36e34067 PMD 0
[ 32.386404] Oops: 0002 [#1] SMP
[ 32.386740] Modules linked in:
[ 32.387040] CPU: 0 PID: 1059 Comm: kworker/u2:2 Not tainted
4.0.0-next-20150427+ #107
[ 32.387762] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
[ 32.388044] Workqueue: writeback bdi_writeback_workfn (flush-9:0)
[ 32.388044] task: 88003d038000 ti: 88003d40c000 task.ti:
88003d40c000
[ 32.388044] RIP: 0010:[] []
add_stripe_bio+0x48d/0x544
[ 32.388044] RSP: :88003d40f6f8 EFLAGS: 00010046
[ 32.388044] RAX: RBX: 880037168cd0 RCX: 880037179a28
[ 32.388044] RDX: 880037168d58 RSI: RDI: 880037179a20
[ 32.388044] RBP: 88003d40f738 R08: 0410 R09: 0410
[ 32.388044] R10: 0410 R11: 0002 R12: 8800371799a0
[ 32.388044] R13: 88003c3d0800 R14: 0001 R15: 880037179a08
[ 32.388044] FS: () GS:88003fc0()
knlGS:
[ 32.388044] CS: 0010 DS: ES: CR0: 8005003b
[ 32.388044] CR2: CR3: 36e33000 CR4: 06f0
[ 32.388044] Stack:
[ 32.388044] 0002 880037168d38 88003d40f738
88003c3abd00
[ 32.388044] 88003c2df800 88003c3d0800 0408
88003c3d0b54
[ 32.388044] 88003d40f828 8184b9ea 3d40f7e8
0292
[ 32.388044] Call Trace:
[ 32.388044] [] make_request+0x7a8/0xaee
[ 32.388044] [] ? wait_woken+0x79/0x79
[ 32.388044] [] ? kmem_cache_alloc+0x95/0x1b6
[ 32.388044] [] md_make_request+0xeb/0x1c3
[ 32.388044] [] ? mempool_alloc+0x64/0x127
[ 32.388044] [] generic_make_request+0x9c/0xdb
[ 32.388044] [] submit_bio+0xf6/0x134
[ 32.388044] [] _submit_bh+0x119/0x141
[ 32.388044] [] submit_bh+0x10/0x12
[ 32.388044] []
__block_write_full_page.constprop.30+0x1a3/0x2a4
[ 32.388044] [] ? I_BDEV+0xd/0xd
[ 32.388044] [] block_write_full_page+0xab/0xaf
[ 32.388044] [] blkdev_writepage+0x18/0x1a
[ 32.388044] [] __writepage+0x14/0x2d
[ 32.388044] [] write_cache_pages+0x29a/0x3a7
[ 32.388044] [] ? mapping_tagged+0x14/0x14
[ 32.388044] [] generic_writepages+0x3e/0x56
[ 32.388044] [] do_writepages+0x1e/0x2c
[ 32.388044] [] __writeback_single_inode+0x5b/0x27e
[ 32.388044] [] writeback_sb_inodes+0x1dc/0x358
[ 32.388044] [] __writeback_inodes_wb+0x7f/0xb8
[ 32.388044] [] wb_writeback+0x11a/0x271
[ 32.388044] [] ? global_dirty_limits+0x1b/0xfd
[ 32.388044] [] bdi_writeback_workfn+0x1ae/0x360
[ 32.388044] [] process_one_work+0x1c2/0x340
[ 32.388044] [] worker_thread+0x28b/0x389
[ 32.388044] [] ? cancel_delayed_work_sync+0x15/0x15
[ 32.388044] [] kthread+0xd2/0xda
[ 32.388044] [] ? kthread_create_on_node+0x17c/0x17c
[ 32.388044] [] ret_from_fork+0x42/0x70
[ 32.388044] [] ? kthread_create_on_node+0x17c/0x17c
[ 32.388044] Code: 84 24 90 00 00 00 48 8d 93 88 00 00 00 49 8d 8c 24 88 00
00 00 49 89 94 24 90 00 00 00 48 89 8b 88 00 00 00 48 89 83 90 00 00 00 <48> 89
10 66 41 83 84 24 80 00 00 00 01 3e 0f ba 73 48 06 72 02
[ 32.388044] RIP [] add_stripe_bio+0x48d/0x544
[ 32.388044] RSP
[ 32.388044] CR2:
[ 32.388044] ---[ end trace 2b255d3f55be9eb3 ]---
Cc: Shaohua Li
Signed-off-by: Yuanhan Liu
---
drivers/md/raid5.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 697d77a..7b074f7 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2217,6 +2217,10 @@ static int resize_stripes(struct r5conf *conf, int
newsize)
if (!p)
err = -ENOMEM;
}
+
+ spin_lock_init(>batch_lock);
+ INIT_LIST_HEAD(>batch_list);
+ nsh->batch_head = NULL;
release_stripe(nsh);
}
/* critical section pass, GFP_NOIO no longer needed */
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] mtd: sh_flctl: fix wrapped condition alignment
On Mon, 04 May 2015, Vinod Koul wrote: > On Sat, May 02, 2015 at 09:57:10AM +0200, Nicholas Mc Guire wrote: > > CodingStyle fix only - align function parameters to opening (. > > > This doesnt look any better to me... > True it makes little difference when looking at these few lines I guess though the issue is consistency. thx! hofrat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/4] extcon: adc-jack: Remove the unneeded num_cables field
This patch removes the 'num_cables' filed from 'struct adc_jack_pdata'
because 'struct extcon_dev' contains the 'max_supported' field which
means the number of supported cable of extcon device.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-adc-jack.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index 2bb82e5..768eaed 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -29,7 +29,6 @@
* struct adc_jack_data - internal data for adc_jack device driver
* @edev: extcon device.
* @cable_names: list of supported cables.
- * @num_cables:size of cable_names.
* @adc_conditions:list of adc value conditions.
* @num_conditions:size of adc_conditions.
* @irq: irq number of attach/detach event (0 if not exist).
@@ -42,7 +41,6 @@ struct adc_jack_data {
struct extcon_dev *edev;
const char **cable_names;
- int num_cables;
struct adc_jack_cond *adc_conditions;
int num_conditions;
@@ -114,16 +112,6 @@ static int adc_jack_probe(struct platform_device *pdev)
}
data->edev->name = pdata->name;
- /* Check the length of array and set num_cables */
- for (i = 0; data->edev->supported_cable[i]; i++)
- ;
- if (i == 0 || i > SUPPORTED_CABLE_MAX) {
- dev_err(>dev, "error: pdata->cable_names size = %d\n",
- i - 1);
- return -EINVAL;
- }
- data->num_cables = i;
-
if (!pdata->adc_conditions ||
!pdata->adc_conditions[0].state) {
dev_err(>dev, "error: adc_conditions not defined.\n");
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] extcon: Alter MHL-TA cable name to TA cable name
This patch alters the MHL-TA cable name to TA cable name because MHL-TA is not
standard name. The MHL-TA is MHL cable with charger cable (TA or USB). So, this
patch use the TA cable instead of MHL-TA to inform the charger cable state.
- MHL-TA -> TA
Cc: Jaewon Kim
Cc: Krzysztof Kozlowski
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
---
drivers/extcon/extcon-max77693.c | 12 +---
drivers/extcon/extcon-max77843.c | 6 ++
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 652bb13..a4fe7fd 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -208,7 +208,6 @@ enum {
EXTCON_CABLE_SLOW_CHARGER,
EXTCON_CABLE_CHARGE_DOWNSTREAM,
EXTCON_CABLE_MHL,
- EXTCON_CABLE_MHL_TA,
EXTCON_CABLE_JIG,
EXTCON_CABLE_DOCK,
@@ -223,7 +222,6 @@ static const char *max77693_extcon_cable[] = {
[EXTCON_CABLE_SLOW_CHARGER] = "Slow-charger",
[EXTCON_CABLE_CHARGE_DOWNSTREAM]= "Charge-downstream",
[EXTCON_CABLE_MHL] = "MHL",
- [EXTCON_CABLE_MHL_TA] = "MHL-TA",
[EXTCON_CABLE_JIG] = "JIG",
[EXTCON_CABLE_DOCK] = "DOCK",
@@ -802,19 +800,19 @@ static int max77693_muic_chg_handler(struct
max77693_muic_info *info)
case MAX77693_MUIC_GND_MHL:
case MAX77693_MUIC_GND_MHL_VB:
/*
-* MHL cable with MHL-TA(USB/TA) cable
+* MHL cable with USB/TA cable
* - MHL cable include two port(HDMI line and separate
* micro-usb port. When the target connect MHL cable,
-* extcon driver check whether MHL-TA(USB/TA) cable is
-* connected. If MHL-TA cable is connected, extcon
+* extcon driver check whether USB/TA cable is
+* connected. If USB/TA cable is connected, extcon
* driver notify state to notifiee for charging battery.
*
-* Features of 'MHL-TA(USB/TA) with MHL cable'
+* Features of 'USB/TA with MHL cable'
* - Support MHL
* - Support charging through micro-usb port without
* data connection
*/
- extcon_set_cable_state(info->edev, "MHL-TA", attached);
+ extcon_set_cable_state(info->edev, "TA", attached);
if (!cable_attached)
extcon_set_cable_state(info->edev,
"MHL", cable_attached);
diff --git a/drivers/extcon/extcon-max77843.c b/drivers/extcon/extcon-max77843.c
index d64aed4..5746d7b 100644
--- a/drivers/extcon/extcon-max77843.c
+++ b/drivers/extcon/extcon-max77843.c
@@ -126,7 +126,6 @@ enum {
MAX77843_CABLE_FAST_CHARGER,
MAX77843_CABLE_SLOW_CHARGER,
MAX77843_CABLE_MHL,
- MAX77843_CABLE_MHL_TA,
MAX77843_CABLE_JIG,
MAX77843_CABLE_NUM,
@@ -140,7 +139,6 @@ static const char *max77843_extcon_cable[] = {
[MAX77843_CABLE_FAST_CHARGER] = "FAST-CHARGER",
[MAX77843_CABLE_SLOW_CHARGER] = "SLOW-CHARGER",
[MAX77843_CABLE_MHL]= "MHL",
- [MAX77843_CABLE_MHL_TA] = "MHL-TA",
[MAX77843_CABLE_JIG]= "JIG",
};
@@ -529,9 +527,9 @@ static int max77843_muic_chg_handler(struct
max77843_muic_info *info)
/* Charger cable on MHL accessory is attach or detach */
if (gnd_type == MAX77843_MUIC_GND_MHL_VB)
- extcon_set_cable_state(info->edev, "MHL-TA", true);
+ extcon_set_cable_state(info->edev, "TA", true);
else if (gnd_type == MAX77843_MUIC_GND_MHL)
- extcon_set_cable_state(info->edev, "MHL-TA", false);
+ extcon_set_cable_state(info->edev, "TA", false);
break;
case MAX77843_MUIC_CHG_NONE:
break;
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] extcon: Unify the jig cable names on rt8973 and max14577/77693/77843
This patch change the name of various jig cables as 'JIG' because the name of
various jig cables are strange and ambiguous on user-space aspect. They include
the different information of either USB and UART state. It is never important
for user-space process. This patch unifies the name of jig cables as following:
- JIG-USB-ON -->|--> JIG
- JIG-USB-OFF -->|
- JIG-UART-ON -->|
- JIG-UART-OFF -->|
Cc: Jaewon Kim
Cc: Krzysztof Kozlowski
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-max14577.c | 19 +++
drivers/extcon/extcon-max77693.c | 23 +++
drivers/extcon/extcon-max77843.c | 37 -
drivers/extcon/extcon-rt8973a.c | 22 +-
4 files changed, 23 insertions(+), 78 deletions(-)
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 3823aa4..6d5febe 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -155,10 +155,7 @@ enum {
EXTCON_CABLE_FAST_CHARGER,
EXTCON_CABLE_SLOW_CHARGER,
EXTCON_CABLE_CHARGE_DOWNSTREAM,
- EXTCON_CABLE_JIG_USB_ON,
- EXTCON_CABLE_JIG_USB_OFF,
- EXTCON_CABLE_JIG_UART_OFF,
- EXTCON_CABLE_JIG_UART_ON,
+ EXTCON_CABLE_JIG,
_EXTCON_CABLE_NUM,
};
@@ -169,10 +166,7 @@ static const char *max14577_extcon_cable[] = {
[EXTCON_CABLE_FAST_CHARGER] = "Fast-charger",
[EXTCON_CABLE_SLOW_CHARGER] = "Slow-charger",
[EXTCON_CABLE_CHARGE_DOWNSTREAM]= "Charge-downstream",
- [EXTCON_CABLE_JIG_USB_ON] = "JIG-USB-ON",
- [EXTCON_CABLE_JIG_USB_OFF] = "JIG-USB-OFF",
- [EXTCON_CABLE_JIG_UART_OFF] = "JIG-UART-OFF",
- [EXTCON_CABLE_JIG_UART_ON] = "JIG-UART-ON",
+ [EXTCON_CABLE_JIG] = "JIG",
NULL,
};
@@ -348,7 +342,6 @@ static int max14577_muic_get_cable_type(struct
max14577_muic_info *info,
static int max14577_muic_jig_handler(struct max14577_muic_info *info,
int cable_type, bool attached)
{
- char cable_name[32];
int ret = 0;
u8 path = CTRL1_SW_OPEN;
@@ -358,18 +351,12 @@ static int max14577_muic_jig_handler(struct
max14577_muic_info *info,
switch (cable_type) {
case MAX14577_MUIC_ADC_FACTORY_MODE_USB_OFF:/* ADC_JIG_USB_OFF */
- /* PATH:AP_USB */
- strcpy(cable_name, "JIG-USB-OFF");
- path = CTRL1_SW_USB;
- break;
case MAX14577_MUIC_ADC_FACTORY_MODE_USB_ON: /* ADC_JIG_USB_ON */
/* PATH:AP_USB */
- strcpy(cable_name, "JIG-USB-ON");
path = CTRL1_SW_USB;
break;
case MAX14577_MUIC_ADC_FACTORY_MODE_UART_OFF: /* ADC_JIG_UART_OFF */
/* PATH:AP_UART */
- strcpy(cable_name, "JIG-UART-OFF");
path = CTRL1_SW_UART;
break;
default:
@@ -382,7 +369,7 @@ static int max14577_muic_jig_handler(struct
max14577_muic_info *info,
if (ret < 0)
return ret;
- extcon_set_cable_state(info->edev, cable_name, attached);
+ extcon_set_cable_state(info->edev, "JIG", attached);
return 0;
}
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index a66bec8..1079321 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -209,10 +209,7 @@ enum {
EXTCON_CABLE_CHARGE_DOWNSTREAM,
EXTCON_CABLE_MHL,
EXTCON_CABLE_MHL_TA,
- EXTCON_CABLE_JIG_USB_ON,
- EXTCON_CABLE_JIG_USB_OFF,
- EXTCON_CABLE_JIG_UART_OFF,
- EXTCON_CABLE_JIG_UART_ON,
+ EXTCON_CABLE_JIG,
EXTCON_CABLE_DOCK_SMART,
EXTCON_CABLE_DOCK_DESK,
EXTCON_CABLE_DOCK_AUDIO,
@@ -229,10 +226,7 @@ static const char *max77693_extcon_cable[] = {
[EXTCON_CABLE_CHARGE_DOWNSTREAM]= "Charge-downstream",
[EXTCON_CABLE_MHL] = "MHL",
[EXTCON_CABLE_MHL_TA] = "MHL-TA",
- [EXTCON_CABLE_JIG_USB_ON] = "JIG-USB-ON",
- [EXTCON_CABLE_JIG_USB_OFF] = "JIG-USB-OFF",
- [EXTCON_CABLE_JIG_UART_OFF] = "JIG-UART-OFF",
- [EXTCON_CABLE_JIG_UART_ON] = "JIG-UART-ON",
+ [EXTCON_CABLE_JIG] = "JIG",
[EXTCON_CABLE_DOCK_SMART] = "Dock-Smart",
[EXTCON_CABLE_DOCK_DESK]= "Dock-Desk",
[EXTCON_CABLE_DOCK_AUDIO] = "Dock-Audio",
@@ -642,7 +636,6 @@ static int max77693_muic_adc_ground_handler(struct
max77693_muic_info *info)
static int max77693_muic_jig_handler(struct max77693_muic_info *info,
int cable_type, bool attached)
{
- char cable_name[32];
int ret = 0;
u8 path = CONTROL1_SW_OPEN;
@@ -652,23 +645,13 @@ static
[PATCH v2 2/4] extcon: Unify the dock device names on max8997/77693
This patch change the name of various dock devices as 'DOCK' because the name of
various dock devices have not the standard naming rules. The name of dock
devices
include the differenct word but it is ambiguous and never important information
on user-space aspect. This patch unifies the name of dock devices as following:
- Dock-Smart -->|--> DOCK
- Dock-Desk-->|
- Dock-Audio -->|
- Dock-Card-->|
Cc: Krzysztof Kozlowski
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
---
drivers/extcon/extcon-max77693.c | 31 +--
drivers/extcon/extcon-max8997.c | 10 +++---
2 files changed, 16 insertions(+), 25 deletions(-)
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 1079321..652bb13 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -210,9 +210,7 @@ enum {
EXTCON_CABLE_MHL,
EXTCON_CABLE_MHL_TA,
EXTCON_CABLE_JIG,
- EXTCON_CABLE_DOCK_SMART,
- EXTCON_CABLE_DOCK_DESK,
- EXTCON_CABLE_DOCK_AUDIO,
+ EXTCON_CABLE_DOCK,
_EXTCON_CABLE_NUM,
};
@@ -227,9 +225,7 @@ static const char *max77693_extcon_cable[] = {
[EXTCON_CABLE_MHL] = "MHL",
[EXTCON_CABLE_MHL_TA] = "MHL-TA",
[EXTCON_CABLE_JIG] = "JIG",
- [EXTCON_CABLE_DOCK_SMART] = "Dock-Smart",
- [EXTCON_CABLE_DOCK_DESK]= "Dock-Desk",
- [EXTCON_CABLE_DOCK_AUDIO] = "Dock-Audio",
+ [EXTCON_CABLE_DOCK] = "DOCK",
NULL,
};
@@ -501,15 +497,15 @@ static int max77693_muic_dock_handler(struct
max77693_muic_info *info,
}
/*
-* Notify Dock-Smart/MHL state.
-* - Dock-Smart device include three type of cable which
+* Notify Dock/MHL state.
+* - Dock device include three type of cable which
* are HDMI, USB for mouse/keyboard and micro-usb port
-* for USB/TA cable. Dock-Smart device need always exteranl
-* power supply(USB/TA cable through micro-usb cable). Dock-
-* Smart device support screen output of target to separate
+* for USB/TA cable. Dock device need always exteranl
+* power supply(USB/TA cable through micro-usb cable). Dock
+* device support screen output of target to separate
* monitor and mouse/keyboard for desktop mode.
*
-* Features of 'USB/TA cable with Dock-Smart device'
+* Features of 'USB/TA cable with Dock device'
* - Support MHL
* - Support external output feature of audio
* - Support charging through micro-usb port without data
@@ -523,14 +519,14 @@ static int max77693_muic_dock_handler(struct
max77693_muic_info *info,
if (ret < 0)
return ret;
- extcon_set_cable_state(info->edev, "Dock-Smart", attached);
+ extcon_set_cable_state(info->edev, "DOCK", attached);
extcon_set_cable_state(info->edev, "MHL", attached);
goto out;
case MAX77693_MUIC_ADC_AUDIO_MODE_REMOTE: /* Dock-Desk */
- strcpy(dock_name, "Dock-Desk");
+ strcpy(dock_name, "DOCK");
break;
case MAX77693_MUIC_ADC_AV_CABLE_NOLOAD: /* Dock-Audio */
- strcpy(dock_name, "Dock-Audio");
+ strcpy(dock_name, "DOCK");
if (!attached)
extcon_set_cable_state(info->edev, "USB", false);
break;
@@ -847,7 +843,7 @@ static int max77693_muic_chg_handler(struct
max77693_muic_info *info)
extcon_set_cable_state(info->edev, "USB", attached);
if (!cable_attached)
- extcon_set_cable_state(info->edev, "Dock-Audio",
+ extcon_set_cable_state(info->edev, "DOCK",
cable_attached);
break;
case MAX77693_MUIC_ADC_RESERVED_ACC_3: /* Dock-Smart */
@@ -876,8 +872,7 @@ static int max77693_muic_chg_handler(struct
max77693_muic_info *info)
if (ret < 0)
return ret;
- extcon_set_cable_state(info->edev, "Dock-Smart",
- attached);
+ extcon_set_cable_state(info->edev, "DOCK", attached);
extcon_set_cable_state(info->edev, "MHL", attached);
break;
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index 5774e56..da269a1 100644
--- a/drivers/extcon/extcon-max8997.c
+++
[PATCH v2 0/4] extcon: Modify the name of unused external connector
This patchset alter the unused name of external connector (jig/dock/MHL) as following. The name of jig cable and dock device include the non-standard H/W information. On user-space side, this information are not necessary. The extcon core will support the other method to inform the specific H/W information to kernel device driver and framework. For example, extcon core have the plan to add the notifier chain for USB ID/VBUS pin state. If extcon consumer (kernel device driver and framework) use the notifer chain for USB ID/VBUS, they can get the state of both JIG and USB when JIG-USB-ON cable is attached. And last patch removes the unused 'num_cables' filed on extcon-adc-jack.c. 1. jig cable name - JIG-USB-ON -->| - JIG-USB-OFF -->| - JIG-UART-ON -->| - JIG-UART-OFF -->|--> JIG 2. dock device name - Dock-Smart -->| - Dock-Desk-->| - Dock-Audio -->| - Dock-Card-->|--> DOCK 3. MHL-TA cable name - MHL-TA -> TA Changes from v1: - Remove the un-related code about default statement on extcon-max778443.c Chanwoo Choi (4): extcon: Unify the jig cable names on rt8973 and max14577/77693/77843 extcon: Unify the dock device names on max8997/77693 extcon: Alter MHL-TA cable name to TA cable name extcon: adc-jack: Remove the unneeded num_cables field drivers/extcon/extcon-adc-jack.c | 12 drivers/extcon/extcon-max14577.c | 19 ++-- drivers/extcon/extcon-max77693.c | 66 +--- drivers/extcon/extcon-max77843.c | 43 +- drivers/extcon/extcon-max8997.c | 10 ++ drivers/extcon/extcon-rt8973a.c | 22 +++--- 6 files changed, 46 insertions(+), 126 deletions(-) -- 1.8.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 WIP 2/4] i2c-parport: modify driver to use new parport device model
On Sun, May 03, 2015 at 03:33:40PM +0200, Jean Delvare wrote:
> Hi Sudip,
Thanks Jean for your time.
>
> On Tue, 28 Apr 2015 17:00:21 +0530, Sudip Mukherjee wrote:
> > + if (!is_parport(>bus_dev))
> > + return;
>
> Can this actually happen?
i got this idea from i2c_verify_client(), as I was getting problem with
different devices registered with the parallel port. But, anyways, i
guess I will not need it in the next iteration of the WIP and can be
handled in the core level.
>
> > + adapter->pdev = parport_register_dev_model(port, name,
> > + _parport_cb);
> > + kfree(name);
>
> If you can free "name" at this point, this suggests that
> parport_register_dev_model made a copy somehow. In that case, please
> don't use dynamic memory allocation in the first place. Either use a
> static buffer and sprintf to it, or (probably better) pass the instance
> number to parport_register_dev_model() as a separate parameter.
well, first thought - there will be some drivers who will not have multiple
instances. but second thought - if we have separately device name and
instance number, we can just combine them when registering with the device
model, but it will become easier in the probe for the name comparison which
you have pointed out later in your reply.
I will try it out in the next iteration.
>
> > if (!adapter->pdev) {
> > printk(KERN_ERR "i2c-parport: Unable to register with
> > parport\n");
> > goto err_free;
> > @@ -237,39 +266,26 @@ static void i2c_parport_attach(struct parport *port)
> > parport_unregister_device(adapter->pdev);
> > err_free:
> > kfree(adapter);
> > + return;
>
> This return statement serves no purpose.
sorry, it is a leftover from an idea I was trying,
>
> > }
> >
> > -static void i2c_parport_detach(struct parport *port)
> > +static int i2c_parport_probe(struct device *dev)
> > {
> > - struct i2c_par *adapter, *_n;
> > + char *name = dev_name(dev);
>
> This adds the following warning at build time:
>
> CC [M] drivers/i2c/busses/i2c-parport.o
> drivers/i2c/busses/i2c-parport.c: In function ‘i2c_parport_probe’:
> drivers/i2c/busses/i2c-parport.c:274:15: warning: initialization discards
> ‘const’ qualifier from pointer target type [enabled by default]
> char *name = dev_name(dev);
>
> Very easy to fix, just declare "name" as const char *.
I didnot get this warning, maybe I need to upgrade my gcc or will
W=1 show it?
>
> >
> > - /* Walk the list */
> >
> > - return parport_register_driver(_parport_driver);
> > + return parport_register_drv(_parport_driver);
>
> Can't you call parport_register_driver() for both models and decide
> what to do based on which members of struct parport_driver are set?
> This would be less confusing IMHO.
I guess it can be done. let me try it out.
>
> > }
> >
> > + }
> > + mutex_unlock(_list_lock);
>
> Moving all this code here seems inappropriate. What if a parallel port
> is removed from the system while the i2c-parport driver is loaded? I
> think this can happen with laptop docking stations or parallel ports on
> PCI cards for example. Your new model should be able to deal with that,
> so each driver still needs a detach or remove function which the core
> can call on parallel port removal.
ok, will be done.
To be frank, I am actually confused with this part, not only for parport
subsystem but for all the other codes I have seen. We have a remove
function for all subsystems, lets assume PCI, so a pci driver is having
a remove callback. So if the particular pci device is removed then the
remove is called which does all the clearing part. But the driver still
remains registered, then what happens to the driver?
>
my next WIP will have some changes in the core level also, so I shouldnot
add your Tested-by: to it. And I will again request you to check that.
And since Alan has not yet tested it on his backpack cd driver, so
please do not test this series. I will send in the next version in a day
or two. Please test that.
regards
sudip
>
> --
> Jean Delvare
> SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/6] Seeding DRBG with more entropy
Am Sonntag, 3. Mai 2015, 16:58:34 schrieb Theodore Ts'o: Hi Theodore, >On Sun, May 03, 2015 at 05:33:00PM +0200, Stephan Mueller wrote: >> The patch set adds an in-kernel /dev/random equivalent that was discussed >> with Ted Ts'o last July -- see [2] and [3]. A test module for testing the >> asynchronous operation of the in-kernel /dev/random is given with the code >> below. >> >> Ted: shall we really create and maintain a new entropy pool (the >> kernel_pool), or should the in-kernel /dev/random logic draw directly from >> the input_pool? In other words, shall we drop the first patch and update >> the 2nd patch to use input_pool? Also, I would not recommend using the >> blocking_pool as this would mix kernel and user land operation. > >I'd drop the 3rd pool, and just simply block until the non-blocking So, you have no concern to use the same pool that is also used by user land? >pool has been initialized. That's now considered the best practice >for userspace programs, which is to use getrandom(2), which by default >will block until the nonblocking pool has been initialized with an >estimated 128 bits of entropy, and after that point, all of the kernel >users should be quite satisfied with cryptographic entropy. I am not sure that this approach is helpful, because the suggested approach implies using a seeded DRNG and the used get_random_bytes already operates as a (not always seeded) DRNG. If we have a blocking interface in the kernel, I would recommend to make it identical to /dev/random. With the suggested seeding approach for DRBG, we definitely have seed data available to start with. Therefore, re-seeding it from another seeded DRNG (i.e. the nonblocking pool after it is initialized) may not give us too much extra. Therefore, may I propose to link the in-kernel blocking API to the blocking pool and have it behave exactly like /dev/random? > >Certainly from the perspective of the perspective of a NIST evaluator >for a DRBG, using if they're happy using jitterentropy as a noise >source, they should be quite happy using the non-blocking pool as a >noise source, so long as it has been properly initialized. They should definitely be happy with that. Even more so, when it is clear that the DRBG is re-seeded once information theoretical entropy is available. Personally, I feel that only considering the blocking_pool as a good source of entropy because it is constantly seeded with information theoretical entropy makes not much sense as that entropy is always and only used for mechanisms that only exhibit computational strength and *not* information theoretical strength. But I deviate from the topic and do not want to start another entropy discussion. :-) > >As far as the concern of user space being able to block a kernel user >"indefinitely", in practice I really don't think that's going to be an >issue as far as boot-time initialization is concerned. In practice >the urandom pool gets 128 bits of entropy *very* quickly, as in, >before the boot process is finished. Just as an FYI: the word "very" does not apply in all cases. I am about to draft an email about that subject in the near future. But the problem is that on SSD systems or virtual machines, the disk is no source of randomness any more starting with 3.18 where all non-rotational block devices are not used as a seed source any more. We only have interrupts which initialize the nonblocking pool much later (in my Haswell systems around the time index of 20). There are other problems that I would like to report separately. [...] > >(And if the attacker is able to inject arbitrary programs running >during the init sequence, they are almost certainly running as root, >and you've got other problems.) No objections on the last statement :-) Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 8/8] ARM: DTS: dra7x: Integrate sDMA crossbar
On Thu, Apr 09, 2015 at 12:35:54PM +0300, Peter Ujfalusi wrote: > The sDMA requests are routed through the DMA crossbar and without the > crossbar only peripherals using DMA request 0-127 can be used. > Need an ACK from ARM folks before I apply this and the DT ones too please -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: Relax a restriction in sched_rt_can_attach()
On Mon, 2015-05-04 at 07:10 +0200, Mike Galbraith wrote: > On Mon, 2015-05-04 at 12:39 +0800, Zefan Li wrote: > > > >> We are moving toward unified hierarchy where all the cgroup controllers > > >> are bound together, so it would make cgroups easier to use if we have > > >> less > > >> restrictions on attaching tasks between cgroups. > > > > > > Forcing group scheduling overhead on users if they want cpuset or memory > > > cgroup functionality would be far from wonderful. Am I interpreting the > > > implications of this unification/binding properly? > > > > > > (I hope not, surely the plan is not to utterly _destroy_ cgroup utility) > > > > > > > Some degree of flexibility is provided so that you may disable some > > controllers > > in a subtree. For example: > > > > root ---> child1 > > (cpuset,memory,cpu)(cpuset,memory) > > \ > >\-> child2 > >(cpu) > > Whew, that's a relief. Thanks. But somehow I'm not feeling a whole lot better. "May" means if you don't explicitly take some action to disable group scheduling, you get it (I don't care if I have an off button), but that would also seemingly mean that we would then have rt tasks in taskgroups with no bandwidth allocated, ie you have to make group scheduling for rt tasks meaningless until a bandwidth appeared, and to make bandwidth appear, you'd have to stop the world, distribute, continue, no? The current "just say no" seems a lot more sensible. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/8] dmaengine: Add driver for TI DMA crossbar on DRA7x
On Thu, Apr 09, 2015 at 12:35:49PM +0300, Peter Ujfalusi wrote:
> +int omap_dmaxbar_init(void)
> +{
> + return platform_driver_register(_dma_xbar_driver);
> +}
> +arch_initcall(omap_dmaxbar_init);
All looks fine except this bit, I think I did point out this last time as
well, though dont recall your answer. We rather depend on defered probe and
not rely on module ordering.
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] extcon: Modify the name of unused external connector
On 04/30/2015 11:10 AM, Krzysztof Kozlowski wrote:
> On 28.04.2015 17:40, Chanwoo Choi wrote:
>> On Tue, Apr 28, 2015 at 12:43 PM, Krzysztof Kozlowski
>> wrote:
>>> On 27.04.2015 21:31, Chanwoo Choi wrote:
This patchset alter the unused name of external connector (jig/dock/MHL)
as
following. The name of jig cable and dock device include the non-standard
H/W
information. On user-space side, this information are not necessary. The
extcon
core will support the other method to inform the specific H/W information
to
kernel device driver and framework. For example, extcon core have the plan
to add
the notifier chain for USB ID/VBUS pin state. If extcon consumer (kernel
device
driver and framework) use the notifer chain for USB ID/VBUS, they can get
the
state of both JIG and USB when JIG-USB-ON cable is attached.
And last patch removes the unused 'num_cables' filed on extcon-adc-jack.c.
1. jig cable name
- JIG-USB-ON -->|
- JIG-USB-OFF -->|
- JIG-UART-ON -->|
- JIG-UART-OFF -->|--> JIG
2. dock device name
- Dock-Smart -->|
- Dock-Desk-->|
- Dock-Audio -->|
- Dock-Card-->|--> DOCK
3. MHL-TA cable name
- MHL-TA -> TA
>>>
>>>
>>> Hi,
>>>
>>> That makes sense but isn't such change a break of interface with user-space?
>>> The user-space may expect Dock-xxx for Dock.
>>
>> I guess it's possible. But, the "Dock-{Smart|Desk|Audio}" device name are not
>> standard. Their name are only used for Samsung Galaxy S3 (releaesd 3.0
>> kernel) and it is not for mainline kernel.
>>
>> So, I want to make the standard cable name for mainline kernel and
>> user-space.
>> The extcon driver will send the event of 'dock' device with specific
>> external connector which is connected to 'dock' device.
>>
>> For example, Dock-Smart means the Dock device with MHL cable. When
>> Dock-Smart is attached, extcon driver will send the two external
>> connector state of
>> both 'DOCK' and 'MHL'. So, the user-space process will detect the kind of
>> dock
>> by catching both 'DOCK' and 'MHL' uevent.
>
> Okay, one more concern - for Dock-Smart the extcon will send two consecutive
> events (first DOCK, then MHL). So to distinguish this from two separate
> connections of Dock and MHL (user first connects some Dock, disconnects,
> connects MHL), the driver always has to call extcon_set_cable_state(edev,
> "Dock", false) after disconnection.
>
> Without the "disconnect" state this case would mean for userspace "Dock+MHL".
>
> This looks like an important part of API for extcon and for driver
> implementations. So it should be documented somewhere?
There is no document about it. I'll send other patch for the sequence of two
events as following:
- attached
1. DOCK is attached
2. MHL is attached
- detached
1. MHL is detached
2. DOCK is detached
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.19 000/177] 3.19.7-stable review
* Guenter Roeck wrote: > On 05/02/2015 12:00 PM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.19.7 release. > >There are 177 patches in this series, all will be posted as a response > >to this one. If anyone has any issues with these being applied, please > >let me know. > > > >Responses should be made by Mon May 4 18:59:31 UTC 2015. > >Anything received after that time might be too late. > > > > Take two: > > Build results: > total: 125 pass: 112 fail: 13 > Failed builds: > mips:defconfig > mips:allmodconfig > mips:bcm47xx_defconfig > mips:bcm63xx_defconfig > mips:nlm_xlp_defconfig > mips:ath79_defconfig > mips:ar7_defconfig > mips:fuloong2e_defconfig > mips:e55_defconfig > mips:cavium_octeon_defconfig > mips:malta_defconfig > powerpc:defconfig > powerpc:allmodconfig > > Qemu test results: > total: 30 pass: 22 fail: 8 > Failed tests: > mips:mips_malta_defconfig > mips:mips_malta_smp_defconfig > mips:mipsel_malta_defconfig > mips:mipsel_malta_smp_defconfig > mips64:mips_malta64_defconfig > mips64:mips_malta64_smp_defconfig > powerpc:ppc64_book3s_defconfig > powerpc:ppc64_book3s_smp_defconfig > > --- > Error logs: > > mips: > > arch/mips/kernel/unaligned.c: In function 'emulate_load_store_insn': > arch/mips/kernel/unaligned.c:570:4: error: expected '}' before 'else' > > Bisect points to 'MIPS: unaligned: Fix regular load/store instruction > emulation for EVA'. > > --- > powerpc: > > include/linux/bug.h: Assembler messages: > include/linux/bug.h:7: Error: unrecognized opcode: `enum' > include/linux/bug.h:8: Error: junk at end of line, first unrecognized > character is `,' > > As mentioned earlier, bisect points to 'powerpc, jump_label: > Include linux/jump_label.h to get HAVE_JUMP_LABEL define'.'. That commit might be missing its dependencies: c0ccf6f99e3a jump_label: Allow jump labels to be used in assembly 55dd0df781e5 jump_label: Allow asm/jump_label.h to be included in assembly But I don't think the PowerPC commit should be in -stable to begin with, just like the two core patches are not. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
how to have the kernel do udev's job and autoload the right modules ?
Hi, I am experimenting a rc.sysinit without udev. Only creating /dev with mount -t devtmpfs dev /dev It also mounts /proc and /sys and /tmp and /var . So the kernel boots up loading a lot of hardware, but some important modules are not loaded , like sound, network and video. I am not sure how to have them auto loaded by the kernel without udev ? I though kernel would have some kind of auto-loading of the right modules, without needing any help like udev. I don't know the simplest and easiest way to achieve this ? Thanks for your help. Best regard. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: pl300: enable the clock to PL330 dma
2015-05-04 13:28 GMT+09:00 : > From: Dinh Nguyen > > Turn on the clock to the PL330 DMA if there is a clock node provided. Why? There is no explanation in the patch for this important question - why? Amba bus already does this and provide a wrapper function. Additionally that would mess up with runtime PM and clock enable/disable. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
is kernel slower at loading for some hardware ?
Hi, during boot up, I am trying to find where the kernel takes more time to do actions (is slower ?). I looked at dmesg and found some places where it takes more time, but not sure if this is normal : [0.070964] smpboot: CPU0: AMD Athlon(tm) 7750 Dual-Core Processor (fam: 10, model: 02, stepping: 03) [0.175415] Performance Events: AMD PMU driver. [0.248501] NET: Registered protocol family 1 [0.248515] pci :00:01.0: MSI quirk detected; subordinate MSI disabled [1.878384] pci :01:05.0: Video device with shadowed ROM [2.225414] ata3: SATA link down (SStatus 0 SControl 300) [2.392196] ata1: softreset failed (device not ready) [2.392199] ata1: applying PMP SRST workaround and retrying [2.422234] usb 3-1: new low-speed USB device number 2 using ohci-pci [2.559072] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [2.695906] hid-generic 0003:04F3:0103.0002: input: USB HID v1.11 Device [HID 04f3:0103] on usb-:00:12.0-1/input1 [2.882804] tsc: Refined TSC clocksource calibration: 2712.351 MHz [3.059684] ata1: softreset failed (device not ready) [3.059687] ata1: applying PMP SRST workaround and retrying [3.236722] sda: sda1 sda2 [3.236880] sd 0:0:0:0: [sda] Attached SCSI disk [3.472247] input: ImPS/2 Logitech Wheel Mouse as /devices/platform/i8042/serio1/input/input2 [3.475012] md: Waiting for all devices to be available before autodetect [3.526543] Freeing unused kernel memory: 796K (816a3000 - 8176a000) [3.887420] Switched to clocksource tsc [4.953361] random: nonblocking pool is initialized Not sure if it is normal or not...maybe it's just normal behavior or cannot get any faster... Thanks for reading. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] mtd: sh_flctl: fix wrapped condition alignment
On Sat, May 02, 2015 at 09:57:10AM +0200, Nicholas Mc Guire wrote:
> CodingStyle fix only - align function parameters to opening (.
>
This doesnt look any better to me...
--
~Vinod
> Signed-off-by: Nicholas Mc Guire
> ---
>
> Patch was compile tested with ap325rxa_defconfig (implies
> CONFIG_MTD_NAND_SH_FLCTL=y)
>
> Patch is against 4.1-rc1 (localversion-next is -next-20150501)
>
> drivers/mtd/nand/sh_flctl.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/nand/sh_flctl.c b/drivers/mtd/nand/sh_flctl.c
> index ffda530..2078c4d 100644
> --- a/drivers/mtd/nand/sh_flctl.c
> +++ b/drivers/mtd/nand/sh_flctl.c
> @@ -428,8 +428,8 @@ static void read_fiforeg(struct sh_flctl *flctl, int
> rlen, int offset)
>
> /* initiate DMA transfer */
> if (flctl->chan_fifo0_rx && rlen >= 32 &&
> - flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_DEV_TO_MEM) == 0)
> - goto convert; /* DMA success */
> + flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_DEV_TO_MEM) == 0)
> + goto convert; /* DMA success */
>
> /* do polling transfer */
> for (i = 0; i < len_4align; i++) {
> @@ -487,8 +487,8 @@ static void write_ec_fiforeg(struct sh_flctl *flctl, int
> rlen,
>
> /* initiate DMA transfer */
> if (flctl->chan_fifo0_tx && rlen >= 32 &&
> - flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_MEM_TO_DEV) == 0)
> - return; /* DMA success */
> + flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_MEM_TO_DEV) == 0)
> + return; /* DMA success */
>
> /* do polling transfer */
> for (i = 0; i < len_4align; i++) {
> --
> 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: [alsa-devel] [PATCH v5 2/2] mfd: arizona: Update DT binding to support hpdet channel
Dear Lee, This patch includes the documentation about extcon-arizona.c. How are we apply this patch to either mfd git or extcon git? Thanks, Chanwoo Choi On 05/04/2015 01:42 PM, Inha Song wrote: > This patch add device tree bindings for the pdata needed to configure > the Accessory Detect Mode select when Headphone detection. > > Signed-off-by: Inha Song > Acked-by: Lee Jones > Acked-by: Charles Keepax > --- > Documentation/devicetree/bindings/mfd/arizona.txt | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt > b/Documentation/devicetree/bindings/mfd/arizona.txt > index 7665aa9..32a71b7 100644 > --- a/Documentation/devicetree/bindings/mfd/arizona.txt > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt > @@ -62,6 +62,12 @@ Optional properties: > present, the number of values should be less than or equal to the > number of inputs, unspecified inputs will use the chip default. > > + - wlf,hpdet-channel : Headphone detection channel. > +ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL > +ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR > +If this node is not mentioned or if the value is unknown, then > +headphone detection mode is set to HPDETL. > + >- DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified > if > they are being externally supplied. As covered in > Documentation/devicetree/bindings/regulator/regulator.txt > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] mtd: sh_flctl: drop unused variable
On Sun, May 03, 2015 at 10:33:43PM +0300, Laurent Pinchart wrote:
> Hi Nicholas,
>
> Thank you for the patch.
>
> On Saturday 02 May 2015 09:57:08 Nicholas Mc Guire wrote:
> > shdma_tx_submit() called via dmaengine_submit() returns the assigned
> > cookie but this is not used here so the variable and assignment can
> > be dropped.
> >
> > Signed-off-by: Nicholas Mc Guire
>
> I would rephrase the commit message to avoid mentioning shdma_tx_submit() as
> that's not relevant. Something like "dmaengine_submit() returns the assigned
> cookie but this is not used here so the variable and assignment can be
> dropped."
And I am bit surrised about taht. Ideally the driver should use the cookie
to check the status later on...
--
~Vinod
>
> With that fixed,
>
> Acked-by: Laurent Pinchart
>
> > ---
> >
> > V2: As pointed out by Laurent Pinchart
> > the variable and assignment can be dropped but not the call to
> > dmaengine_submit(desc) - fixed up
> >
> > Patch was compile tested with ap325rxa_defconfig (implies
> > CONFIG_MTD_NAND_SH_FLCTL=y)
> >
> > Patch is against 4.1-rc1 (localversion-next is -next-20150501)
> >
> > drivers/mtd/nand/sh_flctl.c |3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/sh_flctl.c b/drivers/mtd/nand/sh_flctl.c
> > index 9b032dd..d1c46e5 100644
> > --- a/drivers/mtd/nand/sh_flctl.c
> > +++ b/drivers/mtd/nand/sh_flctl.c
> > @@ -351,7 +351,6 @@ static int flctl_dma_fifo0_transfer(struct sh_flctl
> > *flctl, unsigned long *buf, struct dma_chan *chan;
> > enum dma_transfer_direction tr_dir;
> > dma_addr_t dma_addr;
> > - dma_cookie_t cookie = -EINVAL;
> > uint32_t reg;
> > int ret = 0;
> > unsigned long time_left;
> > @@ -377,7 +376,7 @@ static int flctl_dma_fifo0_transfer(struct sh_flctl
> > *flctl, unsigned long *buf,
> >
> > desc->callback = flctl_dma_complete;
> > desc->callback_param = flctl;
> > - cookie = dmaengine_submit(desc);
> > + dmaengine_submit(desc);
> >
> > dma_async_issue_pending(chan);
> > } else {
>
> --
> Regards,
>
> Laurent Pinchart
>
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [alsa-devel] [PATCH v5 1/2] extcon: arizona: Add support for select accessory detect mode when headphone detection
On 05/04/2015 01:42 PM, Inha Song wrote: > This patch add support for select accessory detect mode to HPDETL or HPDETR. > Arizona provides a headphone detection circuit on the HPDETL and HPDETR pins > to measure the impedance of an external load connected to the headphone. > > Depending on board design, headphone detect pins can change to HPDETR or > HPDETL. > > Signed-off-by: Inha Song > Acked-by: Lee Jones > Acked-by: Charles Keepax > --- > drivers/extcon/extcon-arizona.c | 38 ++ > include/dt-bindings/mfd/arizona.h | 4 > include/linux/mfd/arizona/pdata.h | 3 +++ > 3 files changed, 37 insertions(+), 8 deletions(-) Appled it on extcon-next branch. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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][PATCHSET] non-recursive link_path_walk() and reducing stack footprint
On Fri, Apr 24, 2015 at 02:42:03PM +0100, Al Viro wrote:
> That avoids this spin_lock() on each absolute symlink at the price of extra
> 32 bits in struct nameidata. It looks like doing on-demand reallocation
> of nd->stack is the right way to go anyway, so the pressure on nameidata size
> is going to be weaker and that might be the right way to go...
OK, on-demand reallocation is done. What I have right now is
* flat MAXSYMLINKS 40, no matter what kind of nesting there might
be.
* purely iterative link_path_walk().
* no damn nameidata on stack for generic_readlink()
* stack footprint of the entire thing independent from the nesting
depth, and about on par with "no symlinks at all" case in mainline.
* some massage towards RCU follow_link done (in the end of queue),
but quite a bit more work remains.
What I've got so far is in vfs.git#link_path_walk; I'm not too happy about
posting a 70-chunk mailbomb, but it really will need review and testing.
It survives xfstests and LTP with no regressions, but it will need
serious profiling, etc., along with RTFS. I tried to keep it in reasonably
small pieces, but there's a lot of them ;-/
FWIW, I've a bit more reorganization plotted out, but it's not far from
where we need to be for RCU follow_link. Some notes:
* I don't believe we want to pass flags to ->follow_link() - it's
much simpler to give the damn thing NULL for dentry in RCU case. In *all*
cases where we might have a change to get the symlink body without blocking
we can do that by inode alone. We obviously want to pass dentry and inode
separately (and in case of fast symlinks we don't hit the filesystem at
all), but that's it - flags isn't needed.
* terminate_walk() should do bulk put_link(). So should the
failure cases of complete_walk(). _Success_ of complete_walk() should
be careful about legitimizing links - it *can* be called with one link
on stack, and be followed by access to link body. Yes, really - do_last()
in O_CREAT case.
* do_last(), lookup_last() and mountpoint_last() ought to
have put_link() done when called on non-empty stack (thus turning the loops
into something like
while ((err = lookup_last(nd)) > 0) {
err = trailing_symlink(nd);
if (err)
break;
}
_After_ the point where they don't need to look at the last component of
name, obviously.
* I think we should leave terminate_walk() to callers in failure
cases of walk_component() and handle_dots(), as well as get_link(). Makes
life simpler in callers, actually. I'll play with that a bit more.
* it might make sense to add the second flag to walk_component(),
in addition to LOOKUP_FOLLOW, meaning "do put_link() once you are done looking
at the name". In principle, it promises simpler logics with unlazy_walk(),
but that's one area I'm still not entirely sure about. Will need to
experiment a bit...
* nd->seq clobbering will need to be dealt with, as discussed upthread.
* I _really_ hate your "let's use the LSB of struct page * to tell
if we need to kunmap()" approach. It's too damn ugly to live. _And_ it's
trivial to avoid - all we need is to have (non-lazy) page_follow_link_light()
and page_symlink() to remove __GFP_HIGHMEM from inode->i_mapping before
ever asking to allocate pages there. That'll suffice, and it makes sense
regardless of RCU work - that kmap/kunmap with potential for minutes in
between (while waiting for stuck NFS server in the middle of symlink traversal)
is simply wrong.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched: Relax a restriction in sched_rt_can_attach()
On Mon, 2015-05-04 at 12:39 +0800, Zefan Li wrote: > >> We are moving toward unified hierarchy where all the cgroup controllers > >> are bound together, so it would make cgroups easier to use if we have less > >> restrictions on attaching tasks between cgroups. > > > > Forcing group scheduling overhead on users if they want cpuset or memory > > cgroup functionality would be far from wonderful. Am I interpreting the > > implications of this unification/binding properly? > > > > (I hope not, surely the plan is not to utterly _destroy_ cgroup utility) > > > > Some degree of flexibility is provided so that you may disable some > controllers > in a subtree. For example: > > root ---> child1 > (cpuset,memory,cpu)(cpuset,memory) > \ >\-> child2 >(cpu) Whew, that's a relief. Thanks. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[alsa-devel] [PATCH v5 0/2] Add support for select accessory detect mode to HPDETL or HPDETR
This set of patches adds support for select accessory detect mode to HPDETL or HPDETR. Changes in v5: - Rebased on extcon-next branch. Changes in v4: - Set the hpdet_channel default value to HPDETL in variable declaration. - Fix the indentation in binding documentation. Changes in v3: - Set the hpdet_channel default value to HPDETL If the value is unknown or invalid. Changes in v2: - Use the value in pdata instead of hpdet_channel in extcon_info. - Wrap arizona_extcon_of_get in IS_ENABLED(CONFIG_OF). - Change hpdet_channel type to unsigned from signed in pdata. - Move ARIZONA_ACCDET_MODE_* define to dt-binding header and directly set it to pdata. Inha Song (2): extcon: arizona: Add support for select accessory detect mode when headphone detection mfd: arizona: Update DT binding to support hpdet channel Documentation/devicetree/bindings/mfd/arizona.txt | 6 drivers/extcon/extcon-arizona.c | 38 ++- include/dt-bindings/mfd/arizona.h | 4 +++ include/linux/mfd/arizona/pdata.h | 3 ++ 4 files changed, 43 insertions(+), 8 deletions(-) -- 2.0.0.390.gcb682f8 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[alsa-devel] [PATCH v5 1/2] extcon: arizona: Add support for select accessory detect mode when headphone detection
This patch add support for select accessory detect mode to HPDETL or HPDETR.
Arizona provides a headphone detection circuit on the HPDETL and HPDETR pins
to measure the impedance of an external load connected to the headphone.
Depending on board design, headphone detect pins can change to HPDETR or HPDETL.
Signed-off-by: Inha Song
Acked-by: Lee Jones
Acked-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c | 38 ++
include/dt-bindings/mfd/arizona.h | 4
include/linux/mfd/arizona/pdata.h | 3 +++
3 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 5e08c35..1ec06b4 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -32,13 +32,10 @@
#include
#include
#include
+#include
#define ARIZONA_MAX_MICD_RANGE 8
-#define ARIZONA_ACCDET_MODE_MIC 0
-#define ARIZONA_ACCDET_MODE_HPL 1
-#define ARIZONA_ACCDET_MODE_HPR 2
-
#define ARIZONA_MICD_CLAMP_MODE_JDL 0x4
#define ARIZONA_MICD_CLAMP_MODE_JDH 0x5
#define ARIZONA_MICD_CLAMP_MODE_JDL_GP5H 0x9
@@ -671,9 +668,9 @@ static void arizona_identify_headphone(struct
arizona_extcon_info *info)
ret = regmap_update_bits(arizona->regmap,
ARIZONA_ACCESSORY_DETECT_MODE_1,
ARIZONA_ACCDET_MODE_MASK,
-ARIZONA_ACCDET_MODE_HPL);
+arizona->pdata.hpdet_channel);
if (ret != 0) {
- dev_err(arizona->dev, "Failed to set HPDETL mode: %d\n", ret);
+ dev_err(arizona->dev, "Failed to set HPDET mode: %d\n", ret);
goto err;
}
@@ -723,9 +720,9 @@ static void arizona_start_hpdet_acc_id(struct
arizona_extcon_info *info)
ARIZONA_ACCESSORY_DETECT_MODE_1,
ARIZONA_ACCDET_SRC | ARIZONA_ACCDET_MODE_MASK,
info->micd_modes[0].src |
-ARIZONA_ACCDET_MODE_HPL);
+arizona->pdata.hpdet_channel);
if (ret != 0) {
- dev_err(arizona->dev, "Failed to set HPDETL mode: %d\n", ret);
+ dev_err(arizona->dev, "Failed to set HPDET mode: %d\n", ret);
goto err;
}
@@ -1121,6 +1118,26 @@ static void arizona_micd_set_level(struct arizona
*arizona, int index,
regmap_update_bits(arizona->regmap, reg, mask, level);
}
+static int arizona_extcon_of_get_pdata(struct arizona *arizona)
+{
+ struct arizona_pdata *pdata = >pdata;
+ unsigned int val = ARIZONA_ACCDET_MODE_HPL;
+
+ of_property_read_u32(arizona->dev->of_node, "wlf,hpdet-channel", );
+ switch (val) {
+ case ARIZONA_ACCDET_MODE_HPL:
+ case ARIZONA_ACCDET_MODE_HPR:
+ pdata->hpdet_channel = val;
+ break;
+ default:
+ dev_err(arizona->dev,
+ "Wrong wlf,hpdet-channel DT value %d\n", val);
+ pdata->hpdet_channel = ARIZONA_ACCDET_MODE_HPL;
+ }
+
+ return 0;
+}
+
static int arizona_extcon_probe(struct platform_device *pdev)
{
struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
@@ -1138,6 +1155,11 @@ static int arizona_extcon_probe(struct platform_device
*pdev)
if (!info)
return -ENOMEM;
+ if (IS_ENABLED(CONFIG_OF)) {
+ if (!dev_get_platdata(arizona->dev))
+ arizona_extcon_of_get_pdata(arizona);
+ }
+
info->micvdd = devm_regulator_get(>dev, "MICVDD");
if (IS_ERR(info->micvdd)) {
ret = PTR_ERR(info->micvdd);
diff --git a/include/dt-bindings/mfd/arizona.h
b/include/dt-bindings/mfd/arizona.h
index c7af7c7..fee48e6 100644
--- a/include/dt-bindings/mfd/arizona.h
+++ b/include/dt-bindings/mfd/arizona.h
@@ -90,4 +90,8 @@
#define ARIZONA_INMODE_SE 1
#define ARIZONA_INMODE_DMIC 2
+#define ARIZONA_ACCDET_MODE_MIC 0
+#define ARIZONA_ACCDET_MODE_HPL 1
+#define ARIZONA_ACCDET_MODE_HPR 2
+
#endif
diff --git a/include/linux/mfd/arizona/pdata.h
b/include/linux/mfd/arizona/pdata.h
index 1789cb0..aa5c48b 100644
--- a/include/linux/mfd/arizona/pdata.h
+++ b/include/linux/mfd/arizona/pdata.h
@@ -121,6 +121,9 @@ struct arizona_pdata {
/** GPIO used for mic isolation with HPDET */
int hpdet_id_gpio;
+ /** Channel to use for headphone detection */
+ unsigned int hpdet_channel;
+
/** Extra debounce timeout used during initial mic detection (ms) */
int micd_detect_debounce;
--
2.0.0.390.gcb682f8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MODSIGN: Change default key details [ver #2]
On Sun, 2015-05-03 at 18:45 -0700, Linus Torvalds wrote: > On Sat, May 2, 2015 at 2:46 AM, Abelardo Ricart III > wrote: > > endif > > > > -signing_key.priv signing_key.x509: x509.genkey > > +signing_key.priv signing_key.x509: | x509.genkey > > Hmm. Thinking some more about this, I'm not entirely convinced. > > With this change, if we change kernel/Makefile to have a different > keysigning authority etc, it won't re-generate the keys, because the > old keys still exist. No? That would be wrong. > That's correct. I was under the impression that having the Makefile generate the signing keys was something that was done just to prevent a build failure with CONFIG_MODULE_SIG but no keys. The comment above the key generation target seems to say that. David Howells' patch to make the key details "more obviously unspecified" seems to be along those lines as well; that those generated keys are simply a generic way to have signed modules without managing your own keys. In that case, the actual contents of x509.genkey would be of little significance because those keys are entirely generic and transient. > I'd much rather see "x509.genkey" be generated with a move-if-changed > pattern, so that it only changes if (a) it didn't exist before or (b) > it actually has new content. > And this would indeed trigger key regeneration by make. But what if I do manage my own keys? As I said, I wouldn't want the Makefile to touch them at all, even if the x509.genkey config is missing or was changed. So we have two use cases here: people who use auto-generated keys and people who use their own keys. Sounds like this could be a good case for having a config option that tells make which group you fall under? Something like "CONFIG_MODULE_SIG_GEN_KEY"? If CONFIG_MODULE_SIG_GEN_KEY=y, keys are (re)generated based on the internal x509.genkey. If CONFIG_MODULE_SIG_GEN_KEY is not set, keys are only (re)generated if they don't already exist, which is what my patch would do (and what the documentation implies should be happening now). > On a tangentially related issue: I figured out why I get those (very > annoying) "X.509 certificate list changed" messages. I made it print > out *what* changed: > > X.509 certificate list changed from ./signing_key.x509 to signing_key.x509 > > Note the "./" difference. > > Linus That Makefile could use a makeover. Pun intended. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[alsa-devel] [PATCH v5 2/2] mfd: arizona: Update DT binding to support hpdet channel
This patch add device tree bindings for the pdata needed to configure the Accessory Detect Mode select when Headphone detection. Signed-off-by: Inha Song Acked-by: Lee Jones Acked-by: Charles Keepax --- Documentation/devicetree/bindings/mfd/arizona.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index 7665aa9..32a71b7 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -62,6 +62,12 @@ Optional properties: present, the number of values should be less than or equal to the number of inputs, unspecified inputs will use the chip default. + - wlf,hpdet-channel : Headphone detection channel. +ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL +ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR +If this node is not mentioned or if the value is unknown, then +headphone detection mode is set to HPDETL. + - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if they are being externally supplied. As covered in Documentation/devicetree/bindings/regulator/regulator.txt -- 2.0.0.390.gcb682f8 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/65] 3.10.77-stable review
On 05/03/2015 12:49 PM, Guenter Roeck wrote:
On 05/02/2015 12:03 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.10.77 release.
There are 65 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Mon May 4 19:00:04 UTC 2015.
Anything received after that time might be too late.
Build results:
total: 127 pass: 113 fail: 14
Failed builds:
arm:allmodconfig
arm:multi_v7_defconfig
arm:bcm2835_defconfig
arm:orion5x_defconfig
arm:kirkwood_defconfig
arm:mvebu_defconfig
mips:allmodconfig
powerpc:allmodconfig
powerpc:ppc6xx_defconfig
s390:defconfig
s390:allmodconfig
sparc64:allmodconfig
x86_64:allyesconfig
x86_64:allmodconfig
Qemu test results:
total: 27 pass: 17 fail: 10
Failed tests:
arm:arm_versatile_defconfig
microblaze:microblaze_defconfig
powerpc:ppc_book3s_defconfig
powerpc:ppc_book3s_smp_defconfig
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig
x86:x86_pc_defconfig
x86:x86_pc_nosmp_defconfig
x86_64:x86_64_pc_defconfig
x86_64:x86_64_pc_nosmp_defconfig
Builds fail with:
kernel/trace/trace_functions_graph.c: In function 'graph_trace_open':
kernel/trace/trace_functions_graph.c:1397:2: error: implicit declaration of
function 'alloc_percpu_gfp' [-Werror=implicit-function-declaration]
kernel/trace/trace_functions_graph.c:1397:36: error: expected expression before
'struct'
Bisect points to 'tracing: Handle ftrace_dump() atomic context in
graph_trace_open()'.
Also, for s390, similar to the error seen in 3.14:
arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':
arch/s390/kernel/suspend.c:141:30: error: '_eshared' undeclared (first use in
this function)
arch/s390/kernel/suspend.c:141:30: note: each undeclared identifier is reported
only once for each function it appears in
arch/s390/kernel/suspend.c:142:28: error: '_stext' undeclared (first use in
this function)
arch/s390/kernel/suspend.c:151:10: error: 'ipl_info' undeclared (first use in
this function)
arch/s390/kernel/suspend.c:151:27: error: 'IPL_TYPE_NSS' undeclared (first use
in this function)
Presumably for the same reason ('s390/hibernate: fix save and restore of kernel
text section').
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched: Relax a restriction in sched_rt_can_attach()
On 2015/5/4 11:13, Mike Galbraith wrote: > On Mon, 2015-05-04 at 08:54 +0800, Zefan Li wrote: >> It's allowed to promote a task from normal to realtime after it has been >> attached to a non-root cgroup, but it will fail if the attaching happens >> after it has become realtime. I don't see how this restriction is useful. > > In the CONFIG_RT_GROUP_SCHED case, promotion will fail is there is no > bandwidth allocated. > Right. I forgot to mention this patch affects !CONFIG_RT_GROUP_SCHED only, though it should be obvious by reading the change. >> We are moving toward unified hierarchy where all the cgroup controllers >> are bound together, so it would make cgroups easier to use if we have less >> restrictions on attaching tasks between cgroups. > > Forcing group scheduling overhead on users if they want cpuset or memory > cgroup functionality would be far from wonderful. Am I interpreting the > implications of this unification/binding properly? > > (I hope not, surely the plan is not to utterly _destroy_ cgroup utility) > Some degree of flexibility is provided so that you may disable some controllers in a subtree. For example: root ---> child1 (cpuset,memory,cpu)(cpuset,memory) \ \-> child2 (cpu) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dmaengine: pl300: enable the clock to PL330 dma
From: Dinh Nguyen Turn on the clock to the PL330 DMA if there is a clock node provided. Signed-off-by: Dinh Nguyen --- drivers/dma/pl330.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c index 0e1f567..82eb641 100644 --- a/drivers/dma/pl330.c +++ b/drivers/dma/pl330.c @@ -2894,6 +2894,10 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id) adev->dev.dma_parms = >dma_parms; + adev->pclk = devm_clk_get(>dev, "apb_pclk"); + if (adev->pclk) + clk_prepare_enable(adev->pclk); + /* * This is the limit for transfers with a buswidth of 1, larger * buswidths will have larger limits. -- 2.2.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: iwlwifi getting stuck with current Linus' tree (646da63172)
On Sun, 2015-05-03 at 23:42 +0200, Jiri Kosina wrote:
> Hi,
>
> so over a past few days, I tried to perform a bisect, but failed as
> expected. The issue is not reliably enough reproducible for me, so I ended
> up with a completely bogus commit.
>
> *However*, now that I have been following the causes and symptoms more
> closely (due to the bisect attempt), I have to confirm that the issue
> happens much more often when the machine is question is physically being
> moved when associated.
>
I am doing this all the time and I don't hit your problem. Without any
logs I don't see how I can help here. Please try to catch logs of the
crash. Thanks.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] net: dsa: mv88e6xxx: unregister mv88e6352 driver
From: Vivien Didelot Date: Fri, 1 May 2015 10:43:52 -0400 > Add the missing unregister for the mv88e6352_switch_driver. > > Signed-off-by: Vivien Didelot Applied, thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] lz4: fix system halt at boot kernel on x86_64
Sometimes, on x86_64, decompression fails with the following
error:
Decompressing Linux...
Decoding failed
-- System halted
This condition is not needed for a 64bit kernel(from commit d5e7caf):
if( ... ||
(op + COPYLENGTH) > oend)
goto _output_error
macro LZ4_SECURE_COPY() tests op and does not copy any data
when op exceeds the value.
added by analogy to lz4_uncompress_unknownoutputsize(...)
Signed-off-by: Krzysztof Kolasa
Tested-by: Alexander Kuleshov
Tested-by: Caleb Jorden
---
lib/lz4/lz4_decompress.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
index f0f5c5c..8a742b1 100644
--- a/lib/lz4/lz4_decompress.c
+++ b/lib/lz4/lz4_decompress.c
@@ -139,8 +139,12 @@ static int lz4_uncompress(const char *source, char *dest,
int osize)
/* Error: request to write beyond destination buffer */
if (cpy > oend)
goto _output_error;
+#if LZ4_ARCH64
+ if ((ref + COPYLENGTH) > oend)
+#else
if ((ref + COPYLENGTH) > oend ||
(op + COPYLENGTH) > oend)
+#endif
goto _output_error;
LZ4_SECURECOPY(ref, op, (oend - COPYLENGTH));
while (op < cpy)
@@ -270,7 +274,13 @@ static int lz4_uncompress_unknownoutputsize(const char
*source, char *dest,
if (cpy > oend - COPYLENGTH) {
if (cpy > oend)
goto _output_error; /* write outside of buf */
-
+#if LZ4_ARCH64
+ if ((ref + COPYLENGTH) > oend)
+#else
+ if ((ref + COPYLENGTH) > oend ||
+ (op + COPYLENGTH) > oend)
+#endif
+ goto _output_error;
LZ4_SECURECOPY(ref, op, (oend - COPYLENGTH));
while (op < cpy)
*op++ = *ref++;
--
2.4.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 0/1] lz4: fix system halt at boot on x86_64
I just upgraded one of my systems from 4.0.0 to 4.0.1, and discovered that it would no longer boot. I tried recompiling my kernel, to see if I had somehow corrupted it, but I got the same results. After searching google for a bit, I discovered the discussion here: Re: [PATCHv2] lz4: fix system halted at boot kernel x86_64 compressed lz4 https://lkml.org/lkml/2015/4/3/453 I tested booting 4.0.1 with gzip compression, and it booted fine. I tested after applying this patch, and it also booted fine. It appears that this patch was never properly submitted to Greg, so this is my pass at trying to have it properly formatted for him. This applies cleanly to 4.0.1. I also tried to clean up the wording a bit for the patch. Please CC me on any response, as I am not yet subscribed to this list. Caleb Jorden (1): lz4: fix system halted at boot kernel on x86_64 lib/lz4/lz4_decompress.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) -- 2.4.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/
[RFC PATCH 1/2] ARM: hisi: fix the indentations in Kconfig
Fix the indentations using tabs instead of spaces to align our code. Signed-off-by: Junling Zheng --- arch/arm/mach-hisi/Kconfig | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig index 83061ad..a12b764 100644 --- a/arch/arm/mach-hisi/Kconfig +++ b/arch/arm/mach-hisi/Kconfig @@ -23,12 +23,12 @@ config ARCH_HI3xxx Support for Hisilicon Hi36xx SoC family config ARCH_HIP01 - bool "Hisilicon HIP01 family" if ARCH_MULTI_V7 - select HAVE_ARM_SCU if SMP - select HAVE_ARM_TWD if SMP - select ARM_GLOBAL_TIMER - help - Support for Hisilicon HIP01 SoC family + bool "Hisilicon HIP01 family" if ARCH_MULTI_V7 + select HAVE_ARM_SCU if SMP + select HAVE_ARM_TWD if SMP + select ARM_GLOBAL_TIMER + help + Support for Hisilicon HIP01 SoC family config ARCH_HIP04 bool "Hisilicon HiP04 Cortex A15 family" if ARCH_MULTI_V7 -- 1.8.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/2] ARM: hisi: replace a few spaces with tabs
Replace a few spaces with tabs in mach-hisi to keep the code style.
Signed-off-by: Junling Zheng
---
arch/arm/mach-hisi/hotplug.c | 4 ++--
arch/arm/mach-hisi/platsmp.c | 10 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c
index a129aae..8cd314c 100644
--- a/arch/arm/mach-hisi/hotplug.c
+++ b/arch/arm/mach-hisi/hotplug.c
@@ -65,8 +65,8 @@
#define PMC0_CPU1_PMC_ENABLE (1 << 7)
#define PMC0_CPU1_POWERDOWN(1 << 3)
-#define HIP01_PERI90x50
-#define PERI9_CPU1_RESET (1 << 1)
+#define HIP01_PERI90x50
+#define PERI9_CPU1_RESET (1 << 1)
enum {
HI3620_CTRL,
diff --git a/arch/arm/mach-hisi/platsmp.c b/arch/arm/mach-hisi/platsmp.c
index 8880c8e..808a3a1 100644
--- a/arch/arm/mach-hisi/platsmp.c
+++ b/arch/arm/mach-hisi/platsmp.c
@@ -135,9 +135,9 @@ struct smp_operations hix5hd2_smp_ops __initdata = {
};
-#define SC_SCTL_REMAP_CLR 0x0100
-#define HIP01_BOOT_ADDRESS 0x8000
-#define REG_SC_CTRL0x000
+#define SC_SCTL_REMAP_CLR 0x0100
+#define HIP01_BOOT_ADDRESS 0x8000
+#define REG_SC_CTRL0x000
void hip01_set_boot_addr(phys_addr_t start_addr, phys_addr_t jump_addr)
{
@@ -177,8 +177,8 @@ static int hip01_boot_secondary(unsigned int cpu, struct
task_struct *idle)
}
struct smp_operations hip01_smp_ops __initdata = {
- .smp_prepare_cpus = hisi_common_smp_prepare_cpus,
- .smp_boot_secondary = hip01_boot_secondary,
+ .smp_prepare_cpus = hisi_common_smp_prepare_cpus,
+ .smp_boot_secondary = hip01_boot_secondary,
};
CPU_METHOD_OF_DECLARE(hi3xxx_smp, "hisilicon,hi3620-smp", _smp_ops);
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/11] drivers/net: include for modular stmmac_platform code
From: Paul Gortmaker Date: Thu, 30 Apr 2015 21:47:42 -0400 > This file is built off of a tristate Kconfig option and also contains > modular function calls so it should explicitly include module.h to > avoid compile breakage during header shuffles done in the future. > > Cc: Giuseppe Cavallaro > Cc: net...@vger.kernel.org > Signed-off-by: Paul Gortmaker Applied, thanks Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
On 05/04/15 at 11:06am, Li, ZhenHua wrote: > Hi baoquan, > Could you paste the kernel log of the first kernel ? Please check the attachment. [0.00] microcode: CPU0 microcode updated early to revision 0x710, date = 2013-06-17 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.0.0+ (b...@dhcp-128-28.nay.redhat.com) (gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) ) #6 SMP Wed Apr 29 16:53:34 CST 2015 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.0.0+ root=/dev/mapper/fedora_dhcp--128--28-root ro rd.lvm.lv=fedora_dhcp-128-28/swap rd.lvm.lv=fedora_dhcp-128-28/n [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x000963ff] usable [0.00] BIOS-e820: [mem 0x00096400-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcb74] usable [0.00] BIOS-e820: [mem 0xcb75-0xcb7dafff] ACPI NVS [0.00] BIOS-e820: [mem 0xcb7db000-0xcbaacfff] reserved [0.00] BIOS-e820: [mem 0xcbaad000-0xcbaaefff] ACPI NVS [0.00] BIOS-e820: [mem 0xcbaaf000-0xcbabafff] reserved [0.00] BIOS-e820: [mem 0xcbabb000-0xcbacdfff] ACPI NVS [0.00] BIOS-e820: [mem 0xcbace000-0xcbb55fff] reserved [0.00] BIOS-e820: [mem 0xcbb56000-0xcbb5dfff] ACPI NVS [0.00] BIOS-e820: [mem 0xcbb5e000-0xcbb70fff] reserved [0.00] BIOS-e820: [mem 0xcbb71000-0xcbff] ACPI NVS [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00042fff] usable [0.00] earlycon: no match for ttyS0,115200 [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] e820: last_pfn = 0x43 max_arch_pfn = 0x4 [0.00] PAT configuration [0-7]: WB WC UC- UC WB WC UC- UC [0.00] e820: last_pfn = 0xcb750 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000f4bc0-0x000f4bcf] mapped at [880f4bc0] [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] init_memory_mapping: [mem 0x42fe0-0x42fff] [0.00] init_memory_mapping: [mem 0x42000-0x42fdf] [0.00] init_memory_mapping: [mem 0x4-0x41fff] [0.00] init_memory_mapping: [mem 0x0010-0xcb74] [0.00] init_memory_mapping: [mem 0x1-0x3] [0.00] RAMDISK: [mem 0x35a94000-0x36d41fff] [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F9810 24 (v02 HPQOEM) [0.00] ACPI: XSDT 0xCBA28078 6C (v01 HPQOEM SLIC-WKS 01072009 AMI 00010013) [0.00] ACPI: FACP 0xCBA304C8 F4 (v04 HPQOEM SLIC-WKS 01072009 AMI 00010013) [0.00] ACPI: DSDT 0xCBA28170 008352 (v02 HPQOEM SLIC-WKS 0102 INTL 20051117) [0.00] ACPI: FACS 0xCBB5BF80 40 [0.00] ACPI: APIC 0xCBA305C0 7E (v03 HPQOEM SLIC-WKS 01072009 AMI 00010013) [0.00] ACPI: MCFG 0xCBA30640 3C (v01 HPQOEM OEMMCFG. 01072009 MSFT 0097) [0.00] ACPI: HPET 0xCBA30680 38 (v01 HPQOEM SLIC-WKS 01072009 AMI. 0004) [0.00] ACPI: ASF! 0xCBA306B8 A0 (v32 INTEL HCG 0001 TFSM 000F4240) [0.00] ACPI: SSDT 0xCBA30758 0058DA (v01 COMPAQ WMI 0001 MSFT 0301) [0.00] ACPI: SLIC 0xCBA36038 000176 (v01 HPQOEM SLIC-WKS 0001 ) [0.00] ACPI: SSDT 0xCBA361B0 06E284 (v02 INTEL CpuPm 4000 INTL 20051117) [0.00] ACPI: DMAR 0xCBAA4438 A0 (v01 A M I OEMDMAR 0001 INTL 0001) [0.00] No NUMA configuration found [0.00] Faking a node at [mem 0x-0x00042fff] [0.00] NODE_DATA(0) allocated [mem 0x42ffea000-0x42fffdfff] [0.00] Reserving 256MB of memory at 592MB for crashkernel (System RAM: 16310MB) [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x0001-0x00042fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x00095fff] [0.00] node 0:
[RFC v1 10/11] genirq: Move field 'msi_desc' from struct irq_data into struct irq_common_data
MSI descriptors are per-irq instead of per irqchip, so move it into
struct irq_common_data.
Signed-off-by: Jiang Liu
---
include/linux/irq.h |8
include/linux/irqdesc.h |2 +-
kernel/irq/chip.c |2 +-
kernel/irq/irqdesc.c|2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 6ac20b3f3053..e08bf8811cc1 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -132,6 +132,7 @@ struct irq_domain;
* @node: node index useful for balancing
* @handler_data: per-IRQ data for the irq_chip methods
* @affinity: IRQ affinity on SMP
+ * @msi_desc: MSI descriptor
*/
struct irq_common_data {
unsigned intstate_use_accessors;
@@ -140,6 +141,7 @@ struct irq_common_data {
#endif
void*handler_data;
cpumask_var_t affinity;
+ struct msi_desc *msi_desc;
};
/**
@@ -155,7 +157,6 @@ struct irq_common_data {
* irq_domain
* @chip_data: platform-specific per-chip private data for the chip
* methods, to allow shared chip implementations
- * @msi_desc: MSI descriptor
*
* The fields here need to overlay the ones in irq_desc until we
* cleaned up the direct references and switched everything over to
@@ -172,7 +173,6 @@ struct irq_data {
struct irq_data *parent_data;
#endif
void*chip_data;
- struct msi_desc *msi_desc;
};
/*
@@ -622,12 +622,12 @@ static inline void *irq_data_get_irq_handler_data(struct
irq_data *d)
static inline struct msi_desc *irq_get_msi_desc(unsigned int irq)
{
struct irq_data *d = irq_get_irq_data(irq);
- return d ? d->msi_desc : NULL;
+ return d ? d->common->msi_desc : NULL;
}
static inline struct msi_desc *irq_data_get_msi(struct irq_data *d)
{
- return d->msi_desc;
+ return d->common->msi_desc;
}
static inline u32 irq_get_trigger_type(unsigned int irq)
diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index 5d5776f40129..81a7231c0379 100644
--- a/include/linux/irqdesc.h
+++ b/include/linux/irqdesc.h
@@ -116,7 +116,7 @@ static inline void *irq_desc_get_handler_data(struct
irq_desc *desc)
static inline struct msi_desc *irq_desc_get_msi_desc(struct irq_desc *desc)
{
- return desc->irq_data.msi_desc;
+ return desc->irq_common_data.msi_desc;
}
/*
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 46c487fc71dd..d7a50974b77d 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -105,7 +105,7 @@ int irq_set_msi_desc_off(unsigned int irq_base, unsigned
int irq_offset,
if (!desc)
return -EINVAL;
- desc->irq_data.msi_desc = entry;
+ desc->irq_common_data.msi_desc = entry;
if (entry && !irq_offset)
entry->irq = irq_base;
irq_put_desc_unlock(desc, flags);
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 2c39a203f78b..358f620c035a 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -74,12 +74,12 @@ static void desc_set_defaults(unsigned int irq, struct
irq_desc *desc, int node,
int cpu;
desc->irq_common_data.handler_data = NULL;
+ desc->irq_common_data.msi_desc = NULL;
desc->irq_data.common = >irq_common_data;
desc->irq_data.irq = irq;
desc->irq_data.chip = _irq_chip;
desc->irq_data.chip_data = NULL;
- desc->irq_data.msi_desc = NULL;
irq_settings_clr_and_set(desc, ~0, _IRQ_DEFAULT_INIT_FLAGS);
irqd_set(>irq_data, IRQD_IRQ_DISABLED);
desc->handle_irq = handle_bad_irq;
--
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/
[RFC v1 09/11] genirq: Use helper function to access irq_data->msi_desc
Use helper function to access irq_data->msi_desc, so we could move
msi_desc from struct irq_data into struct irq_common_data later.
Signed-off-by: Jiang Liu
---
arch/ia64/kernel/msi_ia64.c |2 +-
arch/ia64/sn/kernel/msi_sn.c|2 +-
arch/powerpc/sysdev/xics/ics-opal.c |2 +-
arch/powerpc/sysdev/xics/ics-rtas.c |2 +-
arch/tile/kernel/pci_gx.c |2 +-
drivers/pci/msi.c |2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/ia64/kernel/msi_ia64.c b/arch/ia64/kernel/msi_ia64.c
index 6c50d332b7d7..591b66d21bd1 100644
--- a/arch/ia64/kernel/msi_ia64.c
+++ b/arch/ia64/kernel/msi_ia64.c
@@ -23,7 +23,7 @@ static int ia64_set_msi_irq_affinity(struct irq_data *idata,
if (irq_prepare_move(irq, cpu))
return -1;
- __get_cached_msi_msg(idata->msi_desc, );
+ __get_cached_msi_msg(irq_data_get_msi(idata), );
addr = msg.address_lo;
addr &= MSI_ADDR_DEST_ID_MASK;
diff --git a/arch/ia64/sn/kernel/msi_sn.c b/arch/ia64/sn/kernel/msi_sn.c
index 42b5a13af142..6ccc39b36947 100644
--- a/arch/ia64/sn/kernel/msi_sn.c
+++ b/arch/ia64/sn/kernel/msi_sn.c
@@ -175,7 +175,7 @@ static int sn_set_msi_irq_affinity(struct irq_data *data,
* Release XIO resources for the old MSI PCI address
*/
- __get_cached_msi_msg(data->msi_desc, );
+ __get_cached_msi_msg(irq_data_get_msi(data), );
sn_pdev = (struct pcidev_info *)sn_irq_info->irq_pciioinfo;
pdev = sn_pdev->pdi_linux_pcidev;
provider = SN_PCIDEV_BUSPROVIDER(pdev);
diff --git a/arch/powerpc/sysdev/xics/ics-opal.c
b/arch/powerpc/sysdev/xics/ics-opal.c
index 3996393c254d..a709d81f885a 100644
--- a/arch/powerpc/sysdev/xics/ics-opal.c
+++ b/arch/powerpc/sysdev/xics/ics-opal.c
@@ -72,7 +72,7 @@ static unsigned int ics_opal_startup(struct irq_data *d)
* card, using the MSI mask bits. Firmware doesn't appear to unmask
* at that level, so we do it here by hand.
*/
- if (d->msi_desc)
+ if (irq_data_get_msi(d))
pci_msi_unmask_irq(d);
#endif
diff --git a/arch/powerpc/sysdev/xics/ics-rtas.c
b/arch/powerpc/sysdev/xics/ics-rtas.c
index e2665a9dfc0f..f09a7b3136b2 100644
--- a/arch/powerpc/sysdev/xics/ics-rtas.c
+++ b/arch/powerpc/sysdev/xics/ics-rtas.c
@@ -75,7 +75,7 @@ static unsigned int ics_rtas_startup(struct irq_data *d)
* card, using the MSI mask bits. Firmware doesn't appear to unmask
* at that level, so we do it here by hand.
*/
- if (d->msi_desc)
+ if (irq_data_get_msi(d))
pci_msi_unmask_irq(d);
#endif
/* unmask it */
diff --git a/arch/tile/kernel/pci_gx.c b/arch/tile/kernel/pci_gx.c
index b1df847d0686..1438c60e263d 100644
--- a/arch/tile/kernel/pci_gx.c
+++ b/arch/tile/kernel/pci_gx.c
@@ -1442,7 +1442,7 @@ static struct pci_ops tile_cfg_ops = {
/* MSI support starts here. */
static unsigned int tilegx_msi_startup(struct irq_data *d)
{
- if (d->msi_desc)
+ if (irq_data_get_msi(d))
pci_msi_unmask_irq(d);
return 0;
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index c3e7dfcf9ff5..74b48ea0cf26 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1178,7 +1178,7 @@ EXPORT_SYMBOL(pci_enable_msix_range);
*/
void pci_msi_domain_write_msg(struct irq_data *irq_data, struct msi_msg *msg)
{
- struct msi_desc *desc = irq_data->msi_desc;
+ struct msi_desc *desc = irq_data_get_msi(irq_data);
/*
* For MSI-X desc->irq is always equal to irq_data->irq. For
--
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/
[RFC v1 11/11] genirq: Pass irq_data to helper function __irq_set_chip_handler_name_locked()
For most cases, callers pass irq_data->irq to helper function
__irq_set_chip_handler_name_locked() and then it looks up irq_data again
by calling irq_get_irq_data(irq).
So pass irq_data directly instead of irq_data->irq to
__irq_set_chip_handler_name_locked().
Signed-off-by: Jiang Liu
---
arch/ia64/kernel/iosapic.c |6 +++---
arch/mips/alchemy/common/irq.c |4 ++--
drivers/gpio/gpio-zynq.c|9 -
drivers/irqchip/irq-metag-ext.c |5 ++---
drivers/irqchip/irq-mips-gic.c | 11 ---
include/linux/irqdesc.h |6 +++---
6 files changed, 18 insertions(+), 23 deletions(-)
diff --git a/arch/ia64/kernel/iosapic.c b/arch/ia64/kernel/iosapic.c
index 4d2698d43c39..317993e92cba 100644
--- a/arch/ia64/kernel/iosapic.c
+++ b/arch/ia64/kernel/iosapic.c
@@ -610,9 +610,9 @@ register_intr (unsigned int gsi, int irq, unsigned char
delivery,
chip->name, irq_type->name);
chip = irq_type;
}
- __irq_set_chip_handler_name_locked(irq, chip, trigger == IOSAPIC_EDGE ?
- handle_edge_irq : handle_level_irq,
- NULL);
+ __irq_set_chip_handler_name_locked(irq_get_irq_data(irq), chip,
+ trigger == IOSAPIC_EDGE ? handle_edge_irq : handle_level_irq,
+ NULL);
return 0;
}
diff --git a/arch/mips/alchemy/common/irq.c b/arch/mips/alchemy/common/irq.c
index 6cb60abfdcc9..026c4eed37d5 100644
--- a/arch/mips/alchemy/common/irq.c
+++ b/arch/mips/alchemy/common/irq.c
@@ -491,7 +491,7 @@ static int au1x_ic_settype(struct irq_data *d, unsigned int
flow_type)
default:
ret = -EINVAL;
}
- __irq_set_chip_handler_name_locked(d->irq, chip, handler, name);
+ __irq_set_chip_handler_name_locked(d, chip, handler, name);
wmb();
@@ -703,7 +703,7 @@ static int au1300_gpic_settype(struct irq_data *d, unsigned
int type)
return -EINVAL;
}
- __irq_set_chip_handler_name_locked(d->irq, _gpic, hdl, name);
+ __irq_set_chip_handler_name_locked(d, _gpic, hdl, name);
au1300_gpic_chgcfg(d->irq - ALCHEMY_GPIC_INT_BASE, GPIC_CFG_IC_MASK, s);
diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index 184c4b1b2558..aea6075e5b2e 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -422,13 +422,12 @@ static int zynq_gpio_set_irq_type(struct irq_data
*irq_data, unsigned int type)
writel_relaxed(int_any,
gpio->base_addr + ZYNQ_GPIO_INTANY_OFFSET(bank_num));
- if (type & IRQ_TYPE_LEVEL_MASK) {
- __irq_set_chip_handler_name_locked(irq_data->irq,
+ if (type & IRQ_TYPE_LEVEL_MASK)
+ __irq_set_chip_handler_name_locked(irq_data,
_gpio_level_irqchip, handle_fasteoi_irq, NULL);
- } else {
- __irq_set_chip_handler_name_locked(irq_data->irq,
+ else
+ __irq_set_chip_handler_name_locked(irq_data,
_gpio_edge_irqchip, handle_level_irq, NULL);
- }
return 0;
}
diff --git a/drivers/irqchip/irq-metag-ext.c b/drivers/irqchip/irq-metag-ext.c
index 2cb474ad8809..52e501d8c8f0 100644
--- a/drivers/irqchip/irq-metag-ext.c
+++ b/drivers/irqchip/irq-metag-ext.c
@@ -404,7 +404,6 @@ static int meta_intc_irq_set_type(struct irq_data *data,
unsigned int flow_type)
#ifdef CONFIG_METAG_SUSPEND_MEM
struct meta_intc_priv *priv = _intc_priv;
#endif
- unsigned int irq = data->irq;
irq_hw_number_t hw = data->hwirq;
unsigned int bit = 1 << meta_intc_offset(hw);
void __iomem *level_addr = meta_intc_level_addr(hw);
@@ -413,10 +412,10 @@ static int meta_intc_irq_set_type(struct irq_data *data,
unsigned int flow_type)
/* update the chip/handler */
if (flow_type & IRQ_TYPE_LEVEL_MASK)
- __irq_set_chip_handler_name_locked(irq, _intc_level_chip,
+ __irq_set_chip_handler_name_locked(data, _intc_level_chip,
handle_level_irq, NULL);
else
- __irq_set_chip_handler_name_locked(irq, _intc_edge_chip,
+ __irq_set_chip_handler_name_locked(data, _intc_edge_chip,
handle_edge_irq, NULL);
/* and clear/set the bit in HWLEVELEXT */
diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index 09257c301bd2..fb2e64b1f414 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -365,15 +365,12 @@ static int gic_set_type(struct irq_data *d, unsigned int
type)
break;
}
- if (is_edge) {
- __irq_set_chip_handler_name_locked(d->irq,
- _edge_irq_controller,
+ if (is_edge)
+
Re: [PATCH v3 3/3] proc: add kpageidle file
On Thu, Apr 30, 2015 at 05:50:55PM +0300, Vladimir Davydov wrote:
> On Thu, Apr 30, 2015 at 05:25:31PM +0900, Minchan Kim wrote:
> > On Wed, Apr 29, 2015 at 12:12:48PM +0300, Vladimir Davydov wrote:
> > > On Wed, Apr 29, 2015 at 01:35:36PM +0900, Minchan Kim wrote:
> > > > On Tue, Apr 28, 2015 at 03:24:42PM +0300, Vladimir Davydov wrote:
> > > > > +#ifdef CONFIG_IDLE_PAGE_TRACKING
> > > > > +static struct page *kpageidle_get_page(unsigned long pfn)
> > > > > +{
> > > > > + struct page *page;
> > > > > +
> > > > > + if (!pfn_valid(pfn))
> > > > > + return NULL;
> > > > > + page = pfn_to_page(pfn);
> > > > > + /*
> > > > > + * We are only interested in user memory pages, i.e. pages that
> > > > > are
> > > > > + * allocated and on an LRU list.
> > > > > + */
> > > > > + if (!page || page_count(page) == 0 || !PageLRU(page))
> > > > > + return NULL;
> > > > > + if (!get_page_unless_zero(page))
> > > > > + return NULL;
> > > > > + if (unlikely(!PageLRU(page))) {
> > > >
> > > > What lock protect the check PageLRU?
> > > > If it is racing ClearPageLRU, what happens?
> > >
> > > If we hold a reference to a page and see that it's on an LRU list, it
> > > will surely remain a user memory page at least until we release the
> > > reference to it, so it must be safe to play with idle/young flags. If we
> >
> > The problem is that you pass the page in rmap reverse logic(ie,
> > page_referenced)
> > once you judge it's LRU page so if it is false-positive, what happens?
> > A question is SetPageLRU, PageLRU, ClearPageLRU keeps memory ordering?
> > IOW, all of fields from struct page rmap can acccess should be set up
> > completely
> > before LRU checking. Otherwise, something will be broken.
>
> So, basically you are concerned about the case when we encounter a
> freshly allocated page, which has PG_lru bit set and it's going to
> become anonymous, but it is still in the process of rmap initialization,
> i.e. its ->mapping or ->mapcount may still be uninitialized, right?
>
> AFAICS, page_referenced should handle such pages fine. Look, it only
> needs ->index, ->mapping, and ->mapcount.
>
> If ->mapping is unset, than it is NULL and rmap_walk_anon_lock ->
> page_lock_anon_vma_read will return NULL so that rmap_walk will be a
> no-op.
>
> If ->index is not initialized, than at worst we will go to
> anon_vma_interval_tree_foreach over a wrong interval, in which case we
> will see that the page is actually not mapped in page_referenced_one ->
> page_check_address and again do nothing.
>
> If ->mapcount is not initialized it is -1, and page_lock_anon_vma_read
> will return NULL, just as it does in case ->mapping = NULL.
>
> For file pages, we always take PG_locked before checking ->mapping, so
> it must be valid.
>
> Thanks,
> Vladimir
do_anonymous_page
page_add_new_anon_rmap
atomic_set(>_mapcount, 0);
__page_set_anon_rmap
anon_vma = (void *) anon_vma + PAGE_MAPPING_ANON;
page->mapping = (struct address_space *) anon_vma;
page->index = linear_page_index(vma, address);
lru_cache_add
__pagevec_lru_add_fn
SetPageLRU(page);
During the procedure, there is no lock to prevent race. Then, at least,
we need a write memory barrier to guarantee other fields set up before
SetPageLRU. (Of course, PageLRU should have read-memory barrier to work
well) But I can't find any barrier, either.
IOW, any fields you said could be out of order store without any lock or
memory barrier. You might argue atomic op is a barrier on x86 but it
doesn't guarantee other arches work like that so we need explict momory
barrier or lock.
Let's have a theoretical example.
CPU 0
CPU 1
do_anonymous_page
__page_set_anon_rmap
/* out of order happened so SetPageLRU is done ahead */
SetPageLRU(page)
/* Compilr changed store operation like below */
page->mapping = (struct address_space *) anon_vma;
/* Big stall happens */
/* idletacking
judged it as LRU page so pass the page
in
page_reference */
page_refernced
page_rmapping return true because
page->mapping has some vaule but not complete
so it
calls rmap_walk_file.
it's
okay to pass non-completed anon page in rmap_walk_file?
page->mapping = (struct address_space *)
((void *)page_mapping + PAGE_MAPPING_ANON);
It's too theoretical so it might be hard to happen in real practice.
My point is there is nothing to prevent explict
[RFC v1 07/11] net/mlx4: Cache irq_desc->affinity instead of irq_desc
The field 'affinity' in irq_desc won't change once the irq_desc data
structure is created. So cache irq_desc->affinity instead of irq_desc.
This also helps to hide struct irq_desc from device drivers.
Signed-off-by: Jiang Liu
---
drivers/net/ethernet/mellanox/mlx4/en_cq.c |6 +++---
drivers/net/ethernet/mellanox/mlx4/en_rx.c |5 +
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h |2 +-
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_cq.c
b/drivers/net/ethernet/mellanox/mlx4/en_cq.c
index 22da4d0d0f05..a03a01625398 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_cq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_cq.c
@@ -31,6 +31,7 @@
*
*/
+#include
#include
#include
#include
@@ -135,9 +136,8 @@ int mlx4_en_activate_cq(struct mlx4_en_priv *priv, struct
mlx4_en_cq *cq,
mdev->dev->caps.num_comp_vectors;
}
- cq->irq_desc =
- irq_to_desc(mlx4_eq_get_irq(mdev->dev,
- cq->vector));
+ cq->irq_affinity = irq_get_affinity_mask(
+ mlx4_eq_get_irq(mdev->dev, cq->vector));
} else {
/* For TX we use the same irq per
ring we assigned for the RX*/
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 4fdd3c37e47b..59d8395ef31c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -1022,14 +1022,11 @@ int mlx4_en_poll_rx_cq(struct napi_struct *napi, int
budget)
/* If we used up all the quota - we're probably not done yet... */
if (done == budget) {
int cpu_curr;
- const struct cpumask *aff;
INC_PERF_COUNTER(priv->pstats.napi_quota);
cpu_curr = smp_processor_id();
- aff = irq_desc_get_irq_data(cq->irq_desc)->affinity;
-
- if (likely(cpumask_test_cpu(cpu_curr, aff)))
+ if (likely(cpumask_test_cpu(cpu_curr, cq->irq_affinity)))
return budget;
/* Current cpu is not according to smp_irq_affinity -
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 9de30216b146..5de5e9a51d76 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -357,7 +357,7 @@ struct mlx4_en_cq {
#define CQ_USER_PEND (MLX4_EN_CQ_STATE_POLL | MLX4_EN_CQ_STATE_POLL_YIELD)
spinlock_t poll_lock; /* protects from LLS/napi conflicts */
#endif /* CONFIG_NET_RX_BUSY_POLL */
- struct irq_desc *irq_desc;
+ struct cpumask *irq_affinity;
};
struct mlx4_en_port_profile {
--
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/
[RFC v1 08/11] genirq: Move field 'affinity' from struct irq_data into struct irq_common_data
Irq affinity mask is per-irq instead of per irqchip, so move it into
struct irq_common_data.
Signed-off-by: Jiang Liu
---
include/linux/irq.h | 12 ++--
kernel/irq/irqdesc.c |9 +
kernel/irq/manage.c | 12 ++--
kernel/irq/proc.c|2 +-
4 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index cf386d97b96d..6ac20b3f3053 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -110,8 +110,8 @@ enum {
/*
* Return value for chip->irq_set_affinity()
*
- * IRQ_SET_MASK_OK - OK, core updates irq_data.affinity
- * IRQ_SET_MASK_NOCPY - OK, chip did update irq_data.affinity
+ * IRQ_SET_MASK_OK - OK, core updates irq_common_data.affinity
+ * IRQ_SET_MASK_NOCPY - OK, chip did update irq_common_data.affinity
* IRQ_SET_MASK_OK_DONE- Same as IRQ_SET_MASK_OK for core. Special
code to
* support stacked irqchips, which indicates skipping
* all descendent irqchips.
@@ -131,6 +131,7 @@ struct irq_domain;
* Use accessor functions to deal with it
* @node: node index useful for balancing
* @handler_data: per-IRQ data for the irq_chip methods
+ * @affinity: IRQ affinity on SMP
*/
struct irq_common_data {
unsigned intstate_use_accessors;
@@ -138,6 +139,7 @@ struct irq_common_data {
unsigned intnode;
#endif
void*handler_data;
+ cpumask_var_t affinity;
};
/**
@@ -154,7 +156,6 @@ struct irq_common_data {
* @chip_data: platform-specific per-chip private data for the chip
* methods, to allow shared chip implementations
* @msi_desc: MSI descriptor
- * @affinity: IRQ affinity on SMP
*
* The fields here need to overlay the ones in irq_desc until we
* cleaned up the direct references and switched everything over to
@@ -172,7 +173,6 @@ struct irq_data {
#endif
void*chip_data;
struct msi_desc *msi_desc;
- cpumask_var_t affinity;
};
/*
@@ -653,12 +653,12 @@ static inline int irq_data_get_node(struct irq_data *d)
static inline struct cpumask *irq_get_affinity_mask(int irq)
{
struct irq_data *d = irq_get_irq_data(irq);
- return d ? d->affinity : NULL;
+ return d ? d->common->affinity : NULL;
}
static inline struct cpumask *irq_data_get_affinity_mask(struct irq_data *d)
{
- return d->affinity;
+ return d->common->affinity;
}
unsigned int arch_dynirq_lower_bound(unsigned int from);
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 7f881792ad5f..2c39a203f78b 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -38,12 +38,13 @@ static void __init init_irq_default_affinity(void)
#ifdef CONFIG_SMP
static int alloc_masks(struct irq_desc *desc, gfp_t gfp, int node)
{
- if (!zalloc_cpumask_var_node(>irq_data.affinity, gfp, node))
+ if (!zalloc_cpumask_var_node(>irq_common_data.affinity,
+gfp, node))
return -ENOMEM;
#ifdef CONFIG_GENERIC_PENDING_IRQ
if (!zalloc_cpumask_var_node(>pending_mask, gfp, node)) {
- free_cpumask_var(desc->irq_data.affinity);
+ free_cpumask_var(desc->irq_common_data.affinity);
return -ENOMEM;
}
#endif
@@ -52,7 +53,7 @@ static int alloc_masks(struct irq_desc *desc, gfp_t gfp, int
node)
static void desc_smp_init(struct irq_desc *desc, int node)
{
- cpumask_copy(desc->irq_data.affinity, irq_default_affinity);
+ cpumask_copy(desc->irq_common_data.affinity, irq_default_affinity);
#ifdef CONFIG_GENERIC_PENDING_IRQ
cpumask_clear(desc->pending_mask);
#endif
@@ -124,7 +125,7 @@ static void free_masks(struct irq_desc *desc)
#ifdef CONFIG_GENERIC_PENDING_IRQ
free_cpumask_var(desc->pending_mask);
#endif
- free_cpumask_var(desc->irq_data.affinity);
+ free_cpumask_var(desc->irq_common_data.affinity);
}
#else
static inline void free_masks(struct irq_desc *desc) { }
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index d206aa2c3378..7588bf87e8f3 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -190,7 +190,7 @@ int irq_do_set_affinity(struct irq_data *data, const struct
cpumask *mask,
switch (ret) {
case IRQ_SET_MASK_OK:
case IRQ_SET_MASK_OK_DONE:
- cpumask_copy(data->affinity, mask);
+ cpumask_copy(desc->irq_common_data.affinity, mask);
case IRQ_SET_MASK_OK_NOCOPY:
irq_set_thread_affinity(desc);
ret = 0;
@@ -271,7 +271,7 @@ static void irq_affinity_notify(struct work_struct *work)
if (irq_move_pending(>irq_data))
irq_get_pending(cpumask, desc);
else
- cpumask_copy(cpumask, desc->irq_data.affinity);
+
[RFC][PATCH 2/3] usb: xhci: implement hc_driver notify entry
This patch implements the notify entry defined in hc_driver for xHC
driver. For HCD_MSG_DEV_SUSPEND message, it will issue stop endpoint
command for each endpoint in the device. The Suspend(SP) bit in the
command TRB will be set, which gives xHC a hint about the suspend.
For HCD_MSG_DEV_RESUME, it will ring doorbells for all endpoints
unconditionally. XHC may use these hints to optimize its operation
on endpoint state cashes.
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-hub.c | 2 +-
drivers/usb/host/xhci.c | 28
drivers/usb/host/xhci.h | 3 +++
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 0827d7c..a83e82e 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -266,7 +266,7 @@ int xhci_find_slot_id_by_port(struct usb_hcd *hcd, struct
xhci_hcd *xhci,
* to complete.
* suspend will set to 1, if suspend bit need to set in command.
*/
-static int xhci_stop_device(struct xhci_hcd *xhci, int slot_id, int suspend)
+int xhci_stop_device(struct xhci_hcd *xhci, int slot_id, int suspend)
{
struct xhci_virt_device *virt_dev;
struct xhci_command *cmd;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ec8ac16..1e4aa78 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4917,6 +4917,29 @@ error:
}
EXPORT_SYMBOL_GPL(xhci_gen_setup);
+void xhci_notify(struct usb_hcd *hcd, struct usb_device *udev,
+ enum hcd_notification_type type, void *data)
+{
+ struct xhci_hcd *xhci;
+
+ xhci = hcd_to_xhci(hcd);
+ if (!xhci || !xhci->devs[udev->slot_id])
+ return;
+
+ switch (type) {
+ case HCD_MSG_DEV_SUSPEND:
+ xhci_stop_device(xhci, udev->slot_id, 1);
+ break;
+ case HCD_MSG_DEV_RESUME:
+ xhci_ring_device(xhci, udev->slot_id);
+ break;
+ default:
+ xhci_dbg(xhci, "unknown notification message %d.\n", type);
+ break;
+ }
+
+}
+
static const struct hc_driver xhci_hc_driver = {
.description = "xhci-hcd",
.product_desc = "xHCI Host Controller",
@@ -4976,6 +4999,11 @@ static const struct hc_driver xhci_hc_driver = {
.enable_usb3_lpm_timeout = xhci_enable_usb3_lpm_timeout,
.disable_usb3_lpm_timeout = xhci_disable_usb3_lpm_timeout,
.find_raw_port_number = xhci_find_raw_port_number,
+
+ /*
+* notification call back
+*/
+ .notify = xhci_notify,
};
void xhci_init_driver(struct hc_driver *drv, int (*setup_fn)(struct usb_hcd *))
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 8e421b8..f71c643 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1867,10 +1867,13 @@ u32 xhci_port_state_to_neutral(u32 state);
int xhci_find_slot_id_by_port(struct usb_hcd *hcd, struct xhci_hcd *xhci,
u16 port);
void xhci_ring_device(struct xhci_hcd *xhci, int slot_id);
+int xhci_stop_device(struct xhci_hcd *xhci, int slot_id, int suspend);
/* xHCI contexts */
struct xhci_input_control_ctx *xhci_get_input_control_ctx(struct
xhci_container_ctx *ctx);
struct xhci_slot_ctx *xhci_get_slot_ctx(struct xhci_hcd *xhci, struct
xhci_container_ctx *ctx);
struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci, struct
xhci_container_ctx *ctx, unsigned int ep_index);
+void xhci_notify(struct usb_hcd *hcd, struct usb_device *udev,
+ enum hcd_notification_type type, void *data);
#endif /* __LINUX_XHCI_HCD_H */
--
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/
[RFC][PATCH 3/3] usb: xhci: cleanup unnecessary stop device and ring doorbell operations
There is no need to call xhci_stop_device() and xhci_ring_device() in
hub control and bus suspend functions since all device suspend and
resume have been notified through the new notify entry in hc_driver.
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-hub.c | 47 -
1 file changed, 47 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a83e82e..f12e1b7 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -704,7 +704,6 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
u32 temp, status;
int retval = 0;
__le32 __iomem **port_array;
- int slot_id;
struct xhci_bus_state *bus_state;
u16 link_state = 0;
u16 wake_mask = 0;
@@ -818,17 +817,6 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
goto error;
}
- slot_id = xhci_find_slot_id_by_port(hcd, xhci,
- wIndex + 1);
- if (!slot_id) {
- xhci_warn(xhci, "slot_id is zero\n");
- goto error;
- }
- /* unlock to execute stop endpoint commands */
- spin_unlock_irqrestore(>lock, flags);
- xhci_stop_device(xhci, slot_id, 1);
- spin_lock_irqsave(>lock, flags);
-
xhci_set_link_state(xhci, port_array, wIndex, XDEV_U3);
spin_unlock_irqrestore(>lock, flags);
@@ -876,19 +864,6 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
goto error;
}
- if (link_state == USB_SS_PORT_LS_U3) {
- slot_id = xhci_find_slot_id_by_port(hcd, xhci,
- wIndex + 1);
- if (slot_id) {
- /* unlock to execute stop endpoint
-* commands */
- spin_unlock_irqrestore(>lock,
- flags);
- xhci_stop_device(xhci, slot_id, 1);
- spin_lock_irqsave(>lock, flags);
- }
- }
-
xhci_set_link_state(xhci, port_array, wIndex,
link_state);
@@ -994,14 +969,6 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
XDEV_U0);
}
bus_state->port_c_suspend |= 1 << wIndex;
-
- slot_id = xhci_find_slot_id_by_port(hcd, xhci,
- wIndex + 1);
- if (!slot_id) {
- xhci_dbg(xhci, "slot_id is zero\n");
- goto error;
- }
- xhci_ring_device(xhci, slot_id);
break;
case USB_PORT_FEAT_C_SUSPEND:
bus_state->port_c_suspend &= ~(1 << wIndex);
@@ -1133,20 +1100,12 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
while (port_index--) {
/* suspend the port if the port is not suspended */
u32 t1, t2;
- int slot_id;
t1 = readl(port_array[port_index]);
t2 = xhci_port_state_to_neutral(t1);
if ((t1 & PORT_PE) && !(t1 & PORT_PLS_MASK)) {
xhci_dbg(xhci, "port %d not suspended\n", port_index);
- slot_id = xhci_find_slot_id_by_port(hcd, xhci,
- port_index + 1);
- if (slot_id) {
- spin_unlock_irqrestore(>lock, flags);
- xhci_stop_device(xhci, slot_id, 1);
- spin_lock_irqsave(>lock, flags);
- }
t2 &= ~PORT_PLS_MASK;
t2 |= PORT_LINK_STROBE | XDEV_U3;
set_bit(port_index, _state->bus_suspended);
@@ -1207,7 +1166,6 @@ int xhci_bus_resume(struct usb_hcd *hcd)
/* Check whether need resume ports. If needed
resume port and disable remote wakeup */
u32 temp;
- int slot_id;
temp = readl(port_array[port_index]);
if (DEV_SUPERSPEED(temp))
@@ -1240,11 +1198,6 @@ int xhci_bus_resume(struct usb_hcd *hcd)
/* Clear PLC */
xhci_test_and_clear_bit(xhci,
[RFC][PATCH 1/3] usb: add a hcd notify entry in hc_driver
This patch adds a new entry pointer in hc_driver. With this new entry,
USB core can notify host driver when something happens and host driver
is willing to be notified. One use case of this interface comes from
xHCI compatible host controller driver.
The xHCI spec is designed to allow an xHC implementation to cache the
endpoint state. Caching endpoint state allows an xHC to reduce latency
when handling ERDYs and other USB asynchronous events. However holding
this state in xHC consumes resources and power. The xHCI spec designs
some methods through which host controller driver can hint xHC about
how to optimize its operation, e.g. to determine when it holds state
internally or pushes it out to memory, when to power down logic, etc.
When a USB device is going to suspend, states of all endpoints cached
in the xHC should be pushed out to memory to save power and resources.
Vice versa, when a USB device resumes, those states should be brought
back to the cache. USB core suspends or resumes a USB device by sending
set/clear port feature requests to the parent hub where the USB device
is connected. Unfortunately, these operations are transparent to xHCI
driver unless the USB device is plugged in a root port. This patch
utilizes the notify interface to notify xHCI driver whenever a USB
device's power state is changed.
It is harmless if a USB devices under USB 3.0 host controller suspends
or resumes without a notification to hcd driver. However there may be
less opportunities for power savings and there may be increased latency
for restarting an endpoint. The precise impact will be different for
each xHC implementation. It all depends on what an implementation does
with the hints.
Signed-off-by: Lu Baolu
---
drivers/usb/core/generic.c | 10 --
drivers/usb/core/hcd.c | 23 +++
include/linux/usb/hcd.h| 11 ++-
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/generic.c b/drivers/usb/core/generic.c
index 358ca8d..92bee33 100644
--- a/drivers/usb/core/generic.c
+++ b/drivers/usb/core/generic.c
@@ -211,8 +211,12 @@ static int generic_suspend(struct usb_device *udev,
pm_message_t msg)
/* Non-root devices don't need to do anything for FREEZE or PRETHAW */
else if (msg.event == PM_EVENT_FREEZE || msg.event == PM_EVENT_PRETHAW)
rc = 0;
- else
+ else {
+ hcd_notify(udev, HCD_MSG_DEV_SUSPEND, );
rc = usb_port_suspend(udev, msg);
+ if (rc)
+ hcd_notify(udev, HCD_MSG_DEV_RESUME, );
+ }
return rc;
}
@@ -228,8 +232,10 @@ static int generic_resume(struct usb_device *udev,
pm_message_t msg)
*/
if (!udev->parent)
rc = hcd_bus_resume(udev, msg);
- else
+ else {
rc = usb_port_resume(udev, msg);
+ hcd_notify(udev, HCD_MSG_DEV_RESUME, );
+ }
return rc;
}
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 45a915c..725d611 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2289,6 +2289,29 @@ void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
}
EXPORT_SYMBOL_GPL(usb_hcd_resume_root_hub);
+/**
+ * hcd_notify - notify hcd driver with a message
+ * @udev: USB device
+ * @type: message type of this notification
+ * @data: message type specific data
+ *
+ * Call back to hcd driver to notify an event.
+ */
+void hcd_notify(struct usb_device *udev,
+ enum hcd_notification_type type, void *data)
+{
+ struct usb_hcd *hcd;
+
+ if (!udev)
+ return;
+
+ hcd = bus_to_hcd(udev->bus);
+
+ if (hcd->driver->notify)
+ hcd->driver->notify(hcd, udev, type, data);
+}
+EXPORT_SYMBOL_GPL(hcd_notify);
+
#endif /* CONFIG_PM */
/*-*/
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 68b1e83..bdb422c 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -76,6 +76,11 @@ struct giveback_urb_bh {
struct usb_host_endpoint *completing_ep;
};
+enum hcd_notification_type {
+ HCD_MSG_DEV_SUSPEND = 0,/* USB device suspend */
+ HCD_MSG_DEV_RESUME, /* USB device resume */
+};
+
struct usb_hcd {
/*
@@ -383,7 +388,9 @@ struct hc_driver {
int (*find_raw_port_number)(struct usb_hcd *, int);
/* Call for power on/off the port if necessary */
int (*port_power)(struct usb_hcd *hcd, int portnum, bool enable);
-
+ /* Call to notify hcd when it is necessary. */
+ void(*notify)(struct usb_hcd *, struct usb_device *,
+ enum hcd_notification_type, void *);
};
static inline int hcd_giveback_urb_in_bh(struct usb_hcd *hcd)
@@ -632,6 +639,8 @@ extern void usb_root_hub_lost_power(struct usb_device
*rhdev);
extern int hcd_bus_suspend(struct
[RFC][PATCH 0/3] usb: add a hcd notify entry in hc_driver
This patch adds a new entry pointer in hc_driver. With this new entry, USB core can notify host driver when something happens and host driver is willing to be notified. One use case of this interface comes from xHCI compatible host controller driver. The xHCI spec is designed to allow an xHC implementation to cache the endpoint state. Caching endpoint state allows an xHC to reduce latency when handling ERDYs and other USB asynchronous events. However holding this state in xHC consumes resources and power. The xHCI spec designs some methods through which host controller driver can hint xHC about how to optimize its operation, e.g. to determine when it holds state internally or pushes it out to memory, when to power down logic, etc. When a USB device is going to suspend, states of all endpoints cached in the xHC should be pushed out to memory to save power and resources. Vice versa, when a USB device resumes, those states should be brought back to the cache. USB core suspends or resumes a USB device by sending set/clear port feature requests to the parent hub where the USB device is connected. Unfortunately, these operations are transparent to xHCI driver unless the USB device is plugged in a root port. This patch utilizes the notify interface to notify xHCI driver whenever a USB device's power state is changed. It is harmless if a USB devices under USB 3.0 host controller suspends or resumes without a notification to hcd driver. However there may be less opportunities for power savings and there may be increased latency for restarting an endpoint. The precise impact will be different for each xHC implementation. It all depends on what an implementation does with the hints. Lu Baolu (3): usb: add a hcd notify entry in hc_driver usb: xhci: implement hc_driver notify entry usb: xhci: cleanup unnecessary stop device and ring doorbell operations drivers/usb/core/generic.c | 10 +++-- drivers/usb/core/hcd.c | 23 + drivers/usb/host/xhci-hub.c | 49 + drivers/usb/host/xhci.c | 28 ++ drivers/usb/host/xhci.h | 3 +++ include/linux/usb/hcd.h | 11 +- 6 files changed, 73 insertions(+), 51 deletions(-) -- 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/
[RFC v1 05/11] mn10300: Fix incorrect use of data->affinity
The field affinity in struct irq_data is type of cpumask_var_t, so
we should pass in data->affinity instead of >affinity when
calling cpumask_().
Signed-off-by: Jiang Liu
---
arch/mn10300/kernel/irq.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/mn10300/kernel/irq.c b/arch/mn10300/kernel/irq.c
index 6ab3b73efcf8..480de70f4059 100644
--- a/arch/mn10300/kernel/irq.c
+++ b/arch/mn10300/kernel/irq.c
@@ -320,11 +320,11 @@ void migrate_irqs(void)
if (irqd_is_per_cpu(data))
continue;
- if (cpumask_test_cpu(self, >affinity) &&
+ if (cpumask_test_cpu(self, data->affinity) &&
!cpumask_intersects(_affinity[irq], cpu_online_mask)) {
int cpu_id;
cpu_id = cpumask_first(cpu_online_mask);
- cpumask_set_cpu(cpu_id, >affinity);
+ cpumask_set_cpu(cpu_id, data->affinity);
}
/* We need to operate irq_affinity_online atomically. */
arch_local_cli_save(flags);
@@ -335,7 +335,7 @@ void migrate_irqs(void)
GxICR(irq) = x & GxICR_LEVEL;
tmp = GxICR(irq);
- new = cpumask_any_and(>affinity,
+ new = cpumask_any_and(data->affinity,
cpu_online_mask);
irq_affinity_online[irq] = new;
--
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/
[RFC v1 04/11] genirq: Move field 'handler_data' from struct irq_data into struct irq_common_data
Handler data (handler_data) is per-irq instead of per irqchip, so move
it into struct irq_common_data.
Signed-off-by: Jiang Liu
---
arch/sparc/kernel/irq_64.c| 15 +--
arch/sparc/kernel/sun4d_irq.c |4 ++--
arch/sparc/kernel/sun4m_irq.c |6 --
arch/x86/kernel/apic/msi.c|2 +-
arch/x86/kernel/hpet.c|4 ++--
drivers/gpio/gpio-davinci.c |2 +-
drivers/sh/intc/virq.c|4 ++--
include/linux/irq.h |8
include/linux/irqdesc.h |2 +-
kernel/irq/chip.c |2 +-
kernel/irq/irqdesc.c |3 ++-
11 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/arch/sparc/kernel/irq_64.c b/arch/sparc/kernel/irq_64.c
index 4033c23bdfa6..5130f6e3e68e 100644
--- a/arch/sparc/kernel/irq_64.c
+++ b/arch/sparc/kernel/irq_64.c
@@ -210,21 +210,21 @@ struct irq_handler_data {
static inline unsigned int irq_data_to_handle(struct irq_data *data)
{
- struct irq_handler_data *ihd = data->handler_data;
+ struct irq_handler_data *ihd = irq_data_get_irq_handler_data(data);
return ihd->dev_handle;
}
static inline unsigned int irq_data_to_ino(struct irq_data *data)
{
- struct irq_handler_data *ihd = data->handler_data;
+ struct irq_handler_data *ihd = irq_data_get_irq_handler_data(data);
return ihd->dev_ino;
}
static inline unsigned long irq_data_to_sysino(struct irq_data *data)
{
- struct irq_handler_data *ihd = data->handler_data;
+ struct irq_handler_data *ihd = irq_data_get_irq_handler_data(data);
return ihd->sysino;
}
@@ -370,8 +370,9 @@ static int irq_choose_cpu(unsigned int irq, const struct
cpumask *affinity)
static void sun4u_irq_enable(struct irq_data *data)
{
- struct irq_handler_data *handler_data = data->handler_data;
+ struct irq_handler_data *handler_data;
+ handler_data = irq_data_get_irq_handler_data(data);
if (likely(handler_data)) {
unsigned long cpuid, imap, val;
unsigned int tid;
@@ -393,8 +394,9 @@ static void sun4u_irq_enable(struct irq_data *data)
static int sun4u_set_affinity(struct irq_data *data,
const struct cpumask *mask, bool force)
{
- struct irq_handler_data *handler_data = data->handler_data;
+ struct irq_handler_data *handler_data;
+ handler_data = irq_data_get_irq_handler_data(data);
if (likely(handler_data)) {
unsigned long cpuid, imap, val;
unsigned int tid;
@@ -438,8 +440,9 @@ static void sun4u_irq_disable(struct irq_data *data)
static void sun4u_irq_eoi(struct irq_data *data)
{
- struct irq_handler_data *handler_data = data->handler_data;
+ struct irq_handler_data *handler_data;
+ handler_data = irq_data_get_irq_handler_data(data);
if (likely(handler_data))
upa_writeq(ICLR_IDLE, handler_data->iclr);
}
diff --git a/arch/sparc/kernel/sun4d_irq.c b/arch/sparc/kernel/sun4d_irq.c
index a1bb2675b280..a87d0e47c168 100644
--- a/arch/sparc/kernel/sun4d_irq.c
+++ b/arch/sparc/kernel/sun4d_irq.c
@@ -188,7 +188,7 @@ void sun4d_handler_irq(unsigned int pil, struct pt_regs
*regs)
static void sun4d_mask_irq(struct irq_data *data)
{
- struct sun4d_handler_data *handler_data = data->handler_data;
+ struct sun4d_handler_data *handler_data =
irq_data_get_irq_handler_data(data);
unsigned int real_irq;
#ifdef CONFIG_SMP
int cpuid = handler_data->cpuid;
@@ -206,7 +206,7 @@ static void sun4d_mask_irq(struct irq_data *data)
static void sun4d_unmask_irq(struct irq_data *data)
{
- struct sun4d_handler_data *handler_data = data->handler_data;
+ struct sun4d_handler_data *handler_data =
irq_data_get_irq_handler_data(data);
unsigned int real_irq;
#ifdef CONFIG_SMP
int cpuid = handler_data->cpuid;
diff --git a/arch/sparc/kernel/sun4m_irq.c b/arch/sparc/kernel/sun4m_irq.c
index 8bb3b3fddea7..da737c712fa8 100644
--- a/arch/sparc/kernel/sun4m_irq.c
+++ b/arch/sparc/kernel/sun4m_irq.c
@@ -188,9 +188,10 @@ static unsigned long sun4m_imask[0x50] = {
static void sun4m_mask_irq(struct irq_data *data)
{
- struct sun4m_handler_data *handler_data = data->handler_data;
+ struct sun4m_handler_data *handler_data;
int cpu = smp_processor_id();
+ handler_data = irq_data_get_irq_handler_data(data);
if (handler_data->mask) {
unsigned long flags;
@@ -206,9 +207,10 @@ static void sun4m_mask_irq(struct irq_data *data)
static void sun4m_unmask_irq(struct irq_data *data)
{
- struct sun4m_handler_data *handler_data = data->handler_data;
+ struct sun4m_handler_data *handler_data;
int cpu = smp_processor_id();
+ handler_data = irq_data_get_irq_handler_data(data);
if (handler_data->mask) {
unsigned long flags;
diff --git a/arch/x86/kernel/apic/msi.c
[RFC v1 03/11] genirq: Use CONFIG_NUMA instead of CONFIG_SMP to guard irq_common_data.node
NUMA is enabled by CONFIG_NUMA instead of CONFIG_SMP, so use CONFIG_NUMA
to guard irq_common_data.node.
Signed-off-by: Jiang Liu
---
include/linux/irq.h |4 ++--
kernel/irq/irqdesc.c |4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 3f999a0af713..0138f046642c 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -133,7 +133,7 @@ struct irq_domain;
*/
struct irq_common_data {
unsigned intstate_use_accessors;
-#ifdef CONFIG_SMP
+#ifdef CONFIG_NUMA
unsigned intnode;
#endif
};
@@ -638,7 +638,7 @@ static inline u32 irq_get_trigger_type(unsigned int irq)
static inline int irq_common_data_get_node(struct irq_common_data *d)
{
-#ifdef CONFIG_SMP
+#ifdef CONFIG_NUMA
return d->node;
#else
return 0;
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 20773f073e24..0c3057e42906 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -52,11 +52,13 @@ static int alloc_masks(struct irq_desc *desc, gfp_t gfp,
int node)
static void desc_smp_init(struct irq_desc *desc, int node)
{
- desc->irq_common_data.node = node;
cpumask_copy(desc->irq_data.affinity, irq_default_affinity);
#ifdef CONFIG_GENERIC_PENDING_IRQ
cpumask_clear(desc->pending_mask);
#endif
+#ifdef CONFIG_NUMA
+ desc->irq_common_data.node = node;
+#endif
}
#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/
[RFC v1 02/11] genirq: Move field 'node' from struct irq_data into struct irq_common_data
NUMA node information is per-irq instead of per-irqchip, so move it into
struct irq_common_data.
Signed-off-by: Jiang Liu
---
arch/sh/kernel/irq.c |2 +-
arch/x86/kernel/apic/vector.c |8
arch/x86/platform/uv/uv_irq.c |2 +-
include/linux/irq.h | 20 ++--
kernel/irq/internals.h|5 +
kernel/irq/irqdesc.c | 10 ++
kernel/irq/irqdomain.c|4 ++--
kernel/irq/manage.c |2 +-
kernel/irq/proc.c |2 +-
9 files changed, 35 insertions(+), 20 deletions(-)
diff --git a/arch/sh/kernel/irq.c b/arch/sh/kernel/irq.c
index eb10ff84015c..8dc677cc136b 100644
--- a/arch/sh/kernel/irq.c
+++ b/arch/sh/kernel/irq.c
@@ -227,7 +227,7 @@ void migrate_irqs(void)
for_each_active_irq(irq) {
struct irq_data *data = irq_get_irq_data(irq);
- if (data->node == cpu) {
+ if (irq_data_get_node(data) == cpu) {
unsigned int newcpu = cpumask_any_and(data->affinity,
cpu_online_mask);
if (newcpu >= nr_cpu_ids) {
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 96ce5068a926..983bea2a09ce 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -345,7 +345,7 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain,
unsigned int virq,
struct irq_alloc_info *info = arg;
struct apic_chip_data *data;
struct irq_data *irq_data;
- int i, err;
+ int i, err, node;
if (disable_apic)
return -ENXIO;
@@ -357,12 +357,13 @@ static int x86_vector_alloc_irqs(struct irq_domain
*domain, unsigned int virq,
for (i = 0; i < nr_irqs; i++) {
irq_data = irq_domain_get_irq_data(domain, virq + i);
BUG_ON(!irq_data);
+ node = irq_data_get_node(irq_data);
#ifdef CONFIG_X86_IO_APIC
if (virq + i < nr_legacy_irqs() && legacy_irq_data[virq + i])
data = legacy_irq_data[virq + i];
else
#endif
- data = alloc_apic_chip_data(irq_data->node);
+ data = alloc_apic_chip_data(node);
if (!data) {
err = -ENOMEM;
goto error;
@@ -371,8 +372,7 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain,
unsigned int virq,
irq_data->chip = _controller;
irq_data->chip_data = data;
irq_data->hwirq = virq + i;
- err = assign_irq_vector_policy(virq, irq_data->node, data,
- info);
+ err = assign_irq_vector_policy(virq, node, data, info);
if (err)
goto error;
}
diff --git a/arch/x86/platform/uv/uv_irq.c b/arch/x86/platform/uv/uv_irq.c
index cdf86cd3fd97..bc992b7b041f 100644
--- a/arch/x86/platform/uv/uv_irq.c
+++ b/arch/x86/platform/uv/uv_irq.c
@@ -89,7 +89,7 @@ static int uv_domain_alloc(struct irq_domain *domain,
unsigned int virq,
return -EINVAL;
chip_data = kmalloc_node(sizeof(*chip_data), GFP_KERNEL,
-irq_data->node);
+irq_data_get_node(irq_data));
if (!chip_data)
return -ENOMEM;
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 3b6e0def7f5c..3f999a0af713 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -129,9 +129,13 @@ struct irq_domain;
* struct irq_common_data - per irq data shared by all irqchips
* @state_use_accessors: status information for irq chip functions.
* Use accessor functions to deal with it
+ * @node: node index useful for balancing
*/
struct irq_common_data {
unsigned intstate_use_accessors;
+#ifdef CONFIG_SMP
+ unsigned intnode;
+#endif
};
/**
@@ -139,7 +143,6 @@ struct irq_common_data {
* @mask: precomputed bitmask for accessing the chip registers
* @irq: interrupt number
* @hwirq: hardware interrupt number, local to the interrupt domain
- * @node: node index useful for balancing
* @common:point to data shared by all irqchips
* @chip: low level interrupt hardware access
* @domain:Interrupt translation domain; responsible for mapping
@@ -160,7 +163,6 @@ struct irq_data {
u32 mask;
unsigned intirq;
unsigned long hwirq;
- unsigned intnode;
struct irq_common_data *common;
struct irq_chip *chip;
struct irq_domain *domain;
@@ -634,6 +636,20 @@ static inline u32 irq_get_trigger_type(unsigned int irq)
return d ?
Re: [PATCH] sched: Relax a restriction in sched_rt_can_attach()
On Mon, 2015-05-04 at 08:54 +0800, Zefan Li wrote: > It's allowed to promote a task from normal to realtime after it has been > attached to a non-root cgroup, but it will fail if the attaching happens > after it has become realtime. I don't see how this restriction is useful. In the CONFIG_RT_GROUP_SCHED case, promotion will fail is there is no bandwidth allocated. > We are moving toward unified hierarchy where all the cgroup controllers > are bound together, so it would make cgroups easier to use if we have less > restrictions on attaching tasks between cgroups. Forcing group scheduling overhead on users if they want cpuset or memory cgroup functionality would be far from wonderful. Am I interpreting the implications of this unification/binding properly? (I hope not, surely the plan is not to utterly _destroy_ cgroup utility) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC v1 01/11] genirq: Introduce struct irq_common_data to host shared irq data
With introduction of hierarchy irqdomain, struct irq_data becomes
per-chip instead of per-irq and there may be multiple irq_datas
associated with the same irq. Some per-irq data stored in
struct irq_data now may get duplicated into multiple irq_datas,
and causes inconsistent view.
So introduce struct irq_common_data to host per-irq common data and to
achieve consistent view among irq_chips.
Other patches in this patch set will move common fields from
struct irq_data into struct irq_common_data one by one.
Signed-off-by: Jiang Liu
---
include/linux/irq.h | 54 ---
include/linux/irqdesc.h |1 +
kernel/irq/internals.h | 10 -
kernel/irq/irqdesc.c|1 +
kernel/irq/irqdomain.c |1 +
5 files changed, 40 insertions(+), 27 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 62c6901cab55..3b6e0def7f5c 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -126,13 +126,21 @@ struct msi_desc;
struct irq_domain;
/**
- * struct irq_data - per irq and irq chip data passed down to chip functions
+ * struct irq_common_data - per irq data shared by all irqchips
+ * @state_use_accessors: status information for irq chip functions.
+ * Use accessor functions to deal with it
+ */
+struct irq_common_data {
+ unsigned intstate_use_accessors;
+};
+
+/**
+ * struct irq_data - per irq chip data passed down to chip functions
* @mask: precomputed bitmask for accessing the chip registers
* @irq: interrupt number
* @hwirq: hardware interrupt number, local to the interrupt domain
* @node: node index useful for balancing
- * @state_use_accessors: status information for irq chip functions.
- * Use accessor functions to deal with it
+ * @common:point to data shared by all irqchips
* @chip: low level interrupt hardware access
* @domain:Interrupt translation domain; responsible for mapping
* between hwirq number and linux irq number.
@@ -153,7 +161,7 @@ struct irq_data {
unsigned intirq;
unsigned long hwirq;
unsigned intnode;
- unsigned intstate_use_accessors;
+ struct irq_common_data *common;
struct irq_chip *chip;
struct irq_domain *domain;
#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
@@ -166,7 +174,7 @@ struct irq_data {
};
/*
- * Bit masks for irq_data.state
+ * Bit masks for irq_common_data.state_use_accessors
*
* IRQD_TRIGGER_MASK - Mask for the trigger type bits
* IRQD_SETAFFINITY_PENDING- Affinity setting is pending
@@ -198,34 +206,36 @@ enum {
IRQD_WAKEUP_ARMED = (1 << 19),
};
+#define __irqd_to_state(d) ((d)->common->state_use_accessors)
+
static inline bool irqd_is_setaffinity_pending(struct irq_data *d)
{
- return d->state_use_accessors & IRQD_SETAFFINITY_PENDING;
+ return __irqd_to_state(d) & IRQD_SETAFFINITY_PENDING;
}
static inline bool irqd_is_per_cpu(struct irq_data *d)
{
- return d->state_use_accessors & IRQD_PER_CPU;
+ return __irqd_to_state(d) & IRQD_PER_CPU;
}
static inline bool irqd_can_balance(struct irq_data *d)
{
- return !(d->state_use_accessors & (IRQD_PER_CPU | IRQD_NO_BALANCING));
+ return !(__irqd_to_state(d) & (IRQD_PER_CPU | IRQD_NO_BALANCING));
}
static inline bool irqd_affinity_was_set(struct irq_data *d)
{
- return d->state_use_accessors & IRQD_AFFINITY_SET;
+ return __irqd_to_state(d) & IRQD_AFFINITY_SET;
}
static inline void irqd_mark_affinity_was_set(struct irq_data *d)
{
- d->state_use_accessors |= IRQD_AFFINITY_SET;
+ __irqd_to_state(d) |= IRQD_AFFINITY_SET;
}
static inline u32 irqd_get_trigger_type(struct irq_data *d)
{
- return d->state_use_accessors & IRQD_TRIGGER_MASK;
+ return __irqd_to_state(d) & IRQD_TRIGGER_MASK;
}
/*
@@ -233,43 +243,43 @@ static inline u32 irqd_get_trigger_type(struct irq_data
*d)
*/
static inline void irqd_set_trigger_type(struct irq_data *d, u32 type)
{
- d->state_use_accessors &= ~IRQD_TRIGGER_MASK;
- d->state_use_accessors |= type & IRQD_TRIGGER_MASK;
+ __irqd_to_state(d) &= ~IRQD_TRIGGER_MASK;
+ __irqd_to_state(d) |= type & IRQD_TRIGGER_MASK;
}
static inline bool irqd_is_level_type(struct irq_data *d)
{
- return d->state_use_accessors & IRQD_LEVEL;
+ return __irqd_to_state(d) & IRQD_LEVEL;
}
static inline bool irqd_is_wakeup_set(struct irq_data *d)
{
- return d->state_use_accessors & IRQD_WAKEUP_STATE;
+ return __irqd_to_state(d) & IRQD_WAKEUP_STATE;
}
static inline bool irqd_can_move_in_process_context(struct irq_data *d)
{
- return d->state_use_accessors & IRQD_MOVE_PCNTXT;
+ return __irqd_to_state(d) & IRQD_MOVE_PCNTXT;
}
static
[RFC v1 00/11] Split struct irq_data into common part and per-chip part
Hi all, Now the irq core supports hierarchy irq and stacked irqchips, so there may be multiple irq_datas associated with the same irq. But some fields in struct irq_data are per-irq instance and duplicating those fields into multiple irq_data may cause troubles. So this patch introduces a new data structure 'struct irq_common_data' to host per-irq instance data fields, and struct irq_data will only host per-chip data fields after the conversion. It's based on tip/x86/apic plus these two patches at: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg879700.html And it passes Fengguang's zeroday test suite. Thanks! Gerry Jiang Liu (11): genirq: Introduce struct irq_common_data to host shared irq data genirq: Move field 'node' from struct irq_data into struct irq_common_data genirq: Use CONFIG_NUMA instead of CONFIG_SMP to guard irq_common_data.node genirq: Move field 'handler_data' from struct irq_data into struct irq_common_data mn10300: Fix incorrect use of data->affinity genirq: Introduce helper function irq_data_get_affinity_mask() net/mlx4: Cache irq_desc->affinity instead of irq_desc genirq: Move field 'affinity' from struct irq_data into struct irq_common_data genirq: Use helper function to access irq_data->msi_desc genirq: Move field 'msi_desc' from struct irq_data into struct irq_common_data genirq: Pass irq_data to helper function __irq_set_chip_handler_name_locked() arch/alpha/kernel/irq.c |2 +- arch/arm/kernel/irq.c|4 +- arch/arm64/kernel/irq.c |4 +- arch/blackfin/mach-common/ints-priority.c|3 +- arch/ia64/kernel/iosapic.c |8 +- arch/ia64/kernel/irq.c |6 +- arch/ia64/kernel/msi_ia64.c |6 +- arch/ia64/sn/kernel/msi_sn.c |4 +- arch/metag/kernel/irq.c | 10 ++- arch/mips/alchemy/common/irq.c |4 +- arch/mips/bcm63xx/irq.c |2 +- arch/mips/cavium-octeon/octeon-irq.c | 14 ++-- arch/mips/pmcs-msp71xx/msp_irq_cic.c |3 +- arch/mn10300/kernel/cevt-mn10300.c |2 +- arch/mn10300/kernel/irq.c| 13 +-- arch/parisc/kernel/irq.c | 12 +-- arch/powerpc/kernel/irq.c|2 +- arch/powerpc/sysdev/xics/ics-opal.c |4 +- arch/powerpc/sysdev/xics/ics-rtas.c |4 +- arch/sh/kernel/irq.c |9 ++- arch/sparc/kernel/irq_64.c | 27 --- arch/sparc/kernel/leon_kernel.c |6 +- arch/sparc/kernel/sun4d_irq.c|4 +- arch/sparc/kernel/sun4m_irq.c|6 +- arch/tile/kernel/pci_gx.c|2 +- arch/x86/kernel/apic/io_apic.c |2 +- arch/x86/kernel/apic/msi.c |2 +- arch/x86/kernel/apic/vector.c| 13 ++- arch/x86/kernel/hpet.c |4 +- arch/x86/kernel/irq.c|5 +- arch/x86/platform/uv/uv_irq.c|2 +- arch/xtensa/kernel/irq.c | 10 ++- drivers/gpio/gpio-davinci.c |2 +- drivers/gpio/gpio-zynq.c |9 +-- drivers/irqchip/irq-metag-ext.c |5 +- drivers/irqchip/irq-mips-gic.c | 13 ++- drivers/net/ethernet/mellanox/mlx4/en_cq.c |6 +- drivers/net/ethernet/mellanox/mlx4/en_rx.c |5 +- drivers/net/ethernet/mellanox/mlx4/mlx4_en.h |2 +- drivers/parisc/iosapic.c |2 +- drivers/pci/msi.c|2 +- drivers/sh/intc/chip.c |6 +- drivers/sh/intc/virq.c |4 +- drivers/xen/events/events_base.c |4 +- include/linux/irq.h | 109 +- include/linux/irqdesc.h | 11 +-- kernel/irq/chip.c|4 +- kernel/irq/internals.h | 15 ++-- kernel/irq/irqdesc.c | 27 +++ kernel/irq/irqdomain.c |5 +- kernel/irq/manage.c | 14 ++-- kernel/irq/proc.c|4 +- 52 files changed, 250 insertions(+), 198 deletions(-) -- 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/
linux-next: Tree for May 4
Hi all, Changes since 20150501: Removed tree: virtio (maintainer moved on) The akpm-current tree lost its build failure. Non-merge commits (relative to Linus' tree): 1436 1426 files changed, 81272 insertions(+), 32795 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 213 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (61f06db00e06 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (3b8786ff7a1b ARM: 8352/1: perf: Fix the pmu node name in warning message) Merging m68k-current/for-linus (b24f670b7f5b m68k/mac: Fix out-of-bounds array index in OSS IRQ source initialization) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge-mpe/fixes (0aab3747091d powerpc/powernv: Restore non-volatile CRs after nap) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (acc455cffa75 sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly) Merging net/master (6c3c1eb3c35e Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (bdddbf6996c0 xfrm: fix a race in xfrm_state_lookup_byspi) Merging sound-current/for-linus (88776f366ede ALSA: hda - Add headphone quirk for Lifebook E752) Merging pci-current/for-linus (b787f68c36d4 Linux 4.1-rc1) Merging wireless-drivers/master (f67382186489 ath9k: fix per-packet tx power configuration) Merging driver-core.current/driver-core-linus (b787f68c36d4 Linux 4.1-rc1) Merging tty.current/tty-linus (96a5d18bc133 serial: 8250_pci: Add support for 16 port Exar boards) Merging usb.current/usb-linus (0d3bba0287d4 cdc-acm: prevent infinite loop when parsing CDC headers.) Merging usb-gadget-fixes/fixes (c94e289f195e usb: gadget: remove incorrect __init/__exit annotations) Merging usb-serial-fixes/usb-linus (82ee3aeb9295 USB: visor: Match I330 phone more precisely) Merging staging.current/staging-linus (b787f68c36d4 Linux 4.1-rc1) Merging char-misc.current/char-misc-linus (f26443a8ab76 Merge tag 'extcon-fixes-for-4.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-linus) Merging input-current/for-linus (48853389f206 Merge branch 'next' into for-linus) Merging crypto-current/master (8c98ebd7a6ff crypto: img-hash - CRYPTO_DEV_IMGTEC_HASH should depend on HAS_DMA) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (41d9489319f2 drivers/of: Add empty ranges quirk for PA-Semi) Merging rr-fixes/fixes (f47689345931 lguest: update help text.) Merging vfio-fixes/for-linus (82a0eaab980a vfio-pci: Log device requests more verbosely) Merging kselftest-fixes/fixes (b787f68c36d4 Linux 4.1-rc1) Merging drm-intel-fixes/for-linux-next-fixes (a04f90a33fab drm/i915/chv: Implement WaDisableShadowRegForCpd) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic) Merging arc/for-next (b787f68c36d4 Linux 4.1-rc1) Merging arm/for-next (3b8786ff7a1b ARM: 8352/1: perf:
Re: [PATCH v10 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
Hi baoquan, Could you paste the kernel log of the first kernel ? Thanks Zhenhua On 05/03/2015 04:55 PM, Baoquan He wrote: On 04/29/15 at 07:20pm, Baoquan He wrote: Bad news, I rebuilt a kernel with your patchset on 4.0.0+ (this commit f614c81). Now dmar fault is seen again. The lspci log and kdump log are attached, please check: I found the lspci log previously attached is emtyp, resend it again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] xen: vcpu_info would be reset to wrong place on canceled suspend on PVOPS VM which has multi-cpu
The hypervisor continues assuming that vcpu_info is stored in per-cpu data
which was set up by xen_vcpu_setup(),
while on canceled suspend, the call to xen_hvm_init_shared_info() will now make
the guest think that vcpu_info
is in the shared page, so we do not call xen_hvm_init_shared_info() on suspend
canceled.
Signed-off-by: Charles Ouyang
Reviewed-by: Boris Ostrovsky
---
arch/x86/xen/suspend.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index d949769..b2bed45 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -32,7 +32,8 @@ static void xen_hvm_post_suspend(int suspend_cancelled)
{
#ifdef CONFIG_XEN_PVHVM
int cpu;
- xen_hvm_init_shared_info();
+ if (!suspend_cancelled)
+ xen_hvm_init_shared_info();
xen_callback_vector();
xen_unplug_emulated_devices();
if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: fix module-bound check in setting page attributes
It was introduced in commit f2ca09f381a59 (ARM: 8311/1: Don't use is_module_addr in setting page attributes) We have no need to check start twice, but see if end is also in range. Signed-off-by: Hillf Danton Acked-by: Laura Abbott --- --- a/arch/arm/mm/pageattr.cMon May 4 10:33:49 2015 +++ b/arch/arm/mm/pageattr.cMon May 4 10:35:32 2015 @@ -52,7 +52,7 @@ static int change_memory_common(unsigned if (start < MODULES_VADDR || start >= MODULES_END) return -EINVAL; - if (end < MODULES_VADDR || start >= MODULES_END) + if (end < MODULES_VADDR || end >= MODULES_END) return -EINVAL; data.set_mask = set_mask; -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86, irq: Support CPU vector allocation policies
On NUMA systems, an IO device may be associated with a NUMA node.
It may improve IO performance to allocate resources, such as memory
and interrupts, from device local node.
This patch introduces a mechanism to support CPU vector allocation
policies, so users may choose the best suitable CPU vector allocation
policy. Currently there are two supported allocation policies:
1) allocate CPU vectors from CPUs on device local node
2) allocate CPU vectors from all online CPUs
This mechanism may be used to support NumaConnect systems to allocate
CPU vectors from device local node.
Signed-off-by: Jiang Liu
Cc: Daniel J Blueman
---
Documentation/kernel-parameters.txt |5 +++
arch/x86/kernel/apic/vector.c | 83 +++
2 files changed, 79 insertions(+), 9 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 274252f205b7..5e8b1c6f0677 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3840,6 +3840,11 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
vector= [IA-64,SMP]
vector=percpu: enable percpu vector domain
+ vector_alloc= [x86,SMP]
+ vector_alloc=node: try to allocate CPU vectors from
CPUs on
+ device local node first, fallback to all online CPUs
+ vector_alloc=global: allocate CPU vector from all
online CPUs
+
video= [FB] Frame buffer configuration
See Documentation/fb/modedb.txt.
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 1c7dd42b98c1..96ce5068a926 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -28,6 +28,17 @@ struct apic_chip_data {
u8 move_in_progress : 1;
};
+enum {
+ /* Allocate CPU vectors from CPUs on device local node */
+ X86_VECTOR_POL_NODE = 0x1,
+ /* Allocate CPU vectors from all online CPUs */
+ X86_VECTOR_POL_GLOBAL = 0x2,
+ /* Allocate CPU vectors from caller specified CPUs */
+ X86_VECTOR_POL_CALLER = 0x4,
+ X86_VECTOR_POL_MIN = X86_VECTOR_POL_NODE,
+ X86_VECTOR_POL_MAX = X86_VECTOR_POL_CALLER,
+};
+
struct irq_domain *x86_vector_domain;
static DEFINE_RAW_SPINLOCK(vector_lock);
static cpumask_var_t vector_cpumask;
@@ -35,6 +46,9 @@ static struct irq_chip lapic_controller;
#ifdef CONFIG_X86_IO_APIC
static struct apic_chip_data *legacy_irq_data[NR_IRQS_LEGACY];
#endif
+static unsigned int vector_alloc_policy = X86_VECTOR_POL_NODE |
+ X86_VECTOR_POL_GLOBAL |
+ X86_VECTOR_POL_CALLER;
void lock_vector_lock(void)
{
@@ -258,12 +272,6 @@ void copy_irq_alloc_info(struct irq_alloc_info *dst,
struct irq_alloc_info *src)
memset(dst, 0, sizeof(*dst));
}
-static inline const struct cpumask *
-irq_alloc_info_get_mask(struct irq_alloc_info *info)
-{
- return (!info || !info->mask) ? apic->target_cpus() : info->mask;
-}
-
static void x86_vector_free_irqs(struct irq_domain *domain,
unsigned int virq, unsigned int nr_irqs)
{
@@ -284,12 +292,58 @@ static void x86_vector_free_irqs(struct irq_domain
*domain,
}
}
+static int assign_irq_vector_policy(int irq, int node,
+ struct apic_chip_data *data,
+ struct irq_alloc_info *info)
+{
+ int err = -EBUSY;
+ unsigned int policy;
+ const struct cpumask *mask;
+
+ if (info && info->mask)
+ policy = X86_VECTOR_POL_CALLER;
+ else
+ policy = X86_VECTOR_POL_MIN;
+
+ for (; policy <= X86_VECTOR_POL_MAX; policy <<= 1) {
+ if (!(vector_alloc_policy & policy))
+ continue;
+
+ switch (policy) {
+ case X86_VECTOR_POL_NODE:
+ if (node >= 0)
+ mask = cpumask_of_node(node);
+ else
+ mask = NULL;
+ break;
+ case X86_VECTOR_POL_GLOBAL:
+ mask = apic->target_cpus();
+ break;
+ case X86_VECTOR_POL_CALLER:
+ if (info && info->mask)
+ mask = info->mask;
+ else
+ mask = NULL;
+ break;
+ default:
+ mask = NULL;
+ break;
+ }
+ if (mask) {
+ err = assign_irq_vector(irq, data, mask);
+ if (!err)
+ return 0;
+ }
+ }
+
+ return err;
+}
+
static int
[Patch 1/2] irq_remapping/vt-d: Fix regression caused by commit b106ee63abcc
Commit b106ee63abcc ("irq_remapping/vt-d: Enhance Intel IR driver to
support hierarchical irqdomains") caused a regression, which forgot
to initialize remapping data structures other than the first entry
when setting up remapping entries for multiple MSIs.
Code is written by Thomas and commit message is written by Jiang.
Signed-off-by: Thomas Gleixner
Signed-off-by: Jiang Liu
---
Hi Thomas,
I missed this patch when rebasing my patch set. It may be
fold into commit b106ee63abcc ("irq_remapping/vt-d: Enhance Intel IR
driver to support hierarchical irqdomains").
Thanks!
Gerry
---
drivers/iommu/intel_irq_remapping.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 14d95694fc1b..7ecc6b3180ba 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -1113,7 +1113,7 @@ static int intel_irq_remapping_alloc(struct irq_domain
*domain,
{
struct intel_iommu *iommu = domain->host_data;
struct irq_alloc_info *info = arg;
- struct intel_ir_data *data;
+ struct intel_ir_data *data, *ird;
struct irq_data *irq_data;
struct irq_cfg *irq_cfg;
int i, ret, index;
@@ -1158,14 +1158,20 @@ static int intel_irq_remapping_alloc(struct irq_domain
*domain,
}
if (i > 0) {
- data = kzalloc(sizeof(*data), GFP_KERNEL);
- if (!data)
+ ird = kzalloc(sizeof(*ird), GFP_KERNEL);
+ if (!ird)
goto out_free_data;
+ /* Initialize the common data */
+ ird->irq_2_iommu = data->irq_2_iommu;
+ ird->irq_2_iommu.sub_handle = i;
+ } else {
+ ird = data;
}
+
irq_data->hwirq = (index << 16) + i;
- irq_data->chip_data = data;
+ irq_data->chip_data = ird;
irq_data->chip = _ir_chip;
- intel_irq_remapping_prepare_irte(data, irq_cfg, info, index, i);
+ intel_irq_remapping_prepare_irte(ird, irq_cfg, info, index, i);
irq_set_status_flags(virq + i, IRQ_MOVE_PCNTXT);
}
return 0;
--
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 0/2] Optimize CPU vector allocation for NUMA systems
Hi all, This is a small patch set based on tip/x86/apic. This first patch is a bugfix for tip/x86/apic. And the second patch is an enhancement to optimize CPU vector allocation on NUMA systems. It introduces a mechanism to allocate CPU vectors from device local NUMA node and a kernel parameter to enable/disable the optimization. Thanks! Gerry Jiang Liu (2): irq_remapping/vt-d: Fix regression caused by commit b106ee63abcc x86, irq: Support CPU vector allocation policies Documentation/kernel-parameters.txt |5 +++ arch/x86/kernel/apic/vector.c | 83 +++ drivers/iommu/intel_irq_remapping.c | 16 --- 3 files changed, 90 insertions(+), 14 deletions(-) -- 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/
Linux 4.1-rc2
So the -rc2's have lately been pretty small - looking more like late -rc's than early ones. It *used* to be that I couldn't even post the shortlog, because it was just too big. That's not been the case for the last few releases. I think people tend to take a breather after the merge window, because the -rc3's tend to then be a bit bigger again. But it may just also be that I've just gotten much better at saying "the merge window is over, I'm not taking random stragglers", or that people are just getting better at keeping to the merge window. Whatever the reason, the time of huge -rc2's seems to be happily behind us. So in the 4.1 development cycle we match that new pattern. Even if it's not *quite* as tiny as, say, 3.19-rc2 was (that was really an extreme outlier), 4.10-rc2 is pretty small, and things have generally been fairly quiet. The diffstat is also pretty flat and clean, with the notable exception of the new s390 sha512-based prng. I suspect I should have chomped down on that one too. But the rest really looks like "small fixes", no big new chunks of code. As usual, it's a mixture of driver fixes, arch updates (with s390 really standing out due to that one prng commit), and some filesystem and networking. The attached shortlog gives the details, there's nothing particularly worrisome here. So far 4.1 looks fairly normal. Linus --- Alex Deucher (7): drm/radeon: fix ordering of AVI packet setup drm/radeon: drop dce6_dp_enable drm/radeon/audio: don't enable packets until the end drm/radeon: only mark audio as connected if the monitor supports it (v3) drm/radeon: only enable audio streams if the monitor supports it drm/radeon: adjust pll when audio is not enabled drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5 Alexei Starovoitov (1): bpf: fix 64-bit divide Alexey Khoroshilov (1): pxa168: fix double deallocation of managed resources Amir Vadai (1): net/mlx4_en: Prevent setting invalid RSS hash function Andre Przywara (1): arm64: add missing data types in smp_load_acquire/smp_store_release Andreas Oetken (1): altera tse: add support for fixed-links. Antonio Ospite (2): trivial: net: atl1e: atl1e_hw.h: fix 0x0x prefix trivial: net: systemport: bcmsysport.h: fix 0x0x prefix Axel Lin (1): ASoC: rt5645: Fix mask for setting RT5645_DMIC_2_DP_GPIO12 bit Bard Liao (2): ASoC: rt5677: add register patch for PLL ASoC: rt5677: fixed wrong DMIC ref clock Ben Shelton (1): net/macb: Factor out one-time assignment from loop Benjamin Poirier (2): mlx4: Fix tx ring affinity_mask creation mlx4_en: Use correct loop cursor in error path. Chanho Park (1): ext4 crypto: remove duplicated encryption mode definitions Charles Keepax (1): ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE Chee Nouk Phoon (1): net: eth: altera: Resolve false errors from MSGDMA to TSE Chris Bainbridge (1): ACPI / SBS: Enable battery manager when present Chris Mason (1): Btrfs: don't check for delalloc_bytes in cache_save_setup Chris Metcalf (1): tile: properly use node_isset() on a nodemask_t Christian König (4): drm/radeon: fix lockup when BOs aren't part of the VM on release drm/radeon: reset BOs address after clearing it. drm/radeon: check new address before removing old one drm/radeon: fix userptr return value checking (v2) Christoph Hellwig (4): 3w-sas: fix command completion race 3w-: fix command completion race 3w-9xxx: fix command completion race dm: only initialize the request_queue once Christophe Jaillet (1): s390/3215: free memory in error path Christopher Freeman (1): dmaengine: increment privatecnt when using dma_get_any_slave_channel Daniel Axtens (1): powerpc/powernv: Fix early pci_controller_ops loading. David Ahern (1): net/mlx4_core: Fix unaligned accesses David Gibson (1): ibmveth: Fix off-by-one error in ibmveth_change_mtu() David Howells (1): modsign: change default key details David S. Miller (2): netfilter; Add some missing default cases to switch statements in nft_reject. ipv4: Missing sk_nulls_node_init() in ping_unhash(). Davide Italiano (1): ext4: move check under lock scope to close a race. Dean Nelson (1): arm64: add missing PAGE_ALIGN() to __dma_free() Deepak S (1): drm/i915/chv: Implement WaDisableShadowRegForCpd Eric Dumazet (6): tcp: fix possible deadlock in tcp_send_fin() net: do not deplete pfmemalloc reserve tcp: avoid looping in tcp_send_fin() inet: fix possible panic in reqsk_queue_unlink() net: fix crash in build_skb() net: rfs: fix crash in get_rps_cpus() Erik Hugne (2): tipc: fix random link reset problem tipc: fix node refcount issue Fabio Estevam (1): ASoC: fsl_ssi: Fix platform_get_irq()
Re: [LKP] [mtd] 6b44d910ae7: WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:3547 check_flags+0xae/0x17b()
On Tue, 2015-04-28 at 23:37 +0200, Frans Klaver wrote:
> On Thu, Apr 16, 2015 at 01:27:14PM +0800, Huang Ying wrote:
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > commit 6b44d910ae7de5316fcf1fc828ff4a8d48cac5e2 ("mtd: core: set some
> > defaults when dev.parent is set")
> >
> >
> > [5.566033] [nandsim] warning: read_byte: unexpected data output cycle,
> > state is STATE_READY return 0x0
> > [5.566033] [nandsim] warning: read_byte: unexpected data output cycle,
> > state is STATE_READY return 0x0
> > [5.567490] [nandsim] warning: read_byte: unexpected data output cycle,
> > state is STATE_READY return 0x0
> > [5.567490] [nandsim] warning: read_byte: unexpected data output cycle,
> > state is STATE_READY return 0x0
> > [5.568935] [nandsim] warning: read_byte: unexpected data output cycle,
> > state is STATE_READY return 0x0
> > [5.568935] [nandsim] warning: read_byte: unexpected data output cycle,
> > state is STATE_READY return 0x0
> > [5.570362] [nandsim] warning: read_byte: unexpected data output cycle,
> > state is STATE_READY return 0x0
> > [5.570362] [nandsim] warning: read_byte: unexpected data output cycle,
> > state is STATE_READY return 0x0
> > [5.571786] [nandsim] warning: read_byte: unexpected data output cycle,
> > state is STATE_READY return 0x0
> > [5.571786] [nandsim] warning: read_byte: unexpected data output cycle,
> > state is STATE_READY return 0x0
> > [5.573195] [nandsim] warning: read_byte: unexpected data output cycle,
> > state is STATE_READY return 0x0
> > [5.573195] [nandsim] warning: read_byte: unexpected data output cycle,
> > state is STATE_READY return 0x0
> > [5.574628] nand: device found, Manufacturer ID: 0x98, Chip ID: 0x39
> > [5.574628] nand: device found, Manufacturer ID: 0x98, Chip ID: 0x39
> > [5.575662] nand: Toshiba NAND 128MiB 1,8V 8-bit
> > [5.575662] nand: Toshiba NAND 128MiB 1,8V 8-bit
> > [5.576417] nand: 128 MiB, SLC, erase size: 16 KiB, page size: 512, OOB
> > size: 16
> > [5.576417] nand: 128 MiB, SLC, erase size: 16 KiB, page size: 512, OOB
> > size: 16
> > [5.577576] flash size: 128 MiB
> > [5.577576] flash size: 128 MiB
> > [5.578060] page size: 512 bytes
> > [5.578060] page size: 512 bytes
> > [5.578556] OOB area size: 16 bytes
> > [5.578556] OOB area size: 16 bytes
> > [5.579085] sector size: 16 KiB
> > [5.579085] sector size: 16 KiB
> > [5.579568] pages number: 262144
> > [5.579568] pages number: 262144
> > [5.580114] pages per sector: 32
> > [5.580114] pages per sector: 32
> > [5.580659] bus width: 8
> > [5.580659] bus width: 8
> > [5.581067] bits in sector size: 14
> > [5.581067] bits in sector size: 14
> > [5.581605] bits in page size: 9
> > [5.581605] bits in page size: 9
> > [5.582102] bits in OOB size: 4
> > [5.582102] bits in OOB size: 4
> > [5.582593] flash size with OOB: 135168 KiB
> > [5.582593] flash size with OOB: 135168 KiB
> > [5.583235] page address bytes: 4
> > [5.583235] page address bytes: 4
> > [5.583749] sector address bytes: 3
> > [5.583749] sector address bytes: 3
> > [5.584332] options: 0x42
> > [5.584332] options: 0x42
> > [5.586063] Scanning device for bad blocks
> > [5.586063] Scanning device for bad blocks
> > [5.609792] ftl_cs: FTL header not found.
> > [5.609792] ftl_cs: FTL header not found.
> > [5.612150] Creating 1 MTD partitions on "NAND 128MiB 1,8V 8-bit":
> > [5.612150] Creating 1 MTD partitions on "NAND 128MiB 1,8V 8-bit":
> > [5.613131] 0x-0x0800 : "NAND simulator partition 0"
> > [5.613131] 0x-0x0800 : "NAND simulator partition 0"
> > [5.614496] BUG: unable to handle kernel
> > [5.614496] BUG: unable to handle kernel NULL pointer dereferenceNULL
> > pointer dereference at 0008
> > at 0008
> > [5.615637] IP:
> > [5.615637] IP: [<818c8620>] add_mtd_device+0x194/0x313
> > [<818c8620>] add_mtd_device+0x194/0x313
> > [5.616041] *pde =
> > [5.616041] *pde =
> >
> > [5.616041] Oops: [#1]
> > [5.616041] Oops: [#1] DEBUG_PAGEALLOC DEBUG_PAGEALLOC
> >
> > [5.616041] CPU: 0 PID: 1 Comm: swapper Tainted: GW
> > 4.0.0-08945-gcb973ec #3
> > [5.616041] CPU: 0 PID: 1 Comm: swapper Tainted: GW
> > 4.0.0-08945-gcb973ec #3
> > [5.616041] task: 9468 ti: 94688000 task.ti: 94688000
> > [5.616041] task: 9468 ti: 94688000 task.ti: 94688000
> > [5.616041] EIP: 0060:[<818c8620>] EFLAGS: 00010202 CPU: 0
> > [5.616041] EIP: 0060:[<818c8620>] EFLAGS: 00010202 CPU: 0
> > [5.616041] EIP is at add_mtd_device+0x194/0x313
> > [5.616041] EIP is at add_mtd_device+0x194/0x313
> > [5.616041] EAX: 8bc100f0 EBX: 0001 ECX: 0001 EDX:
> > [
mm: VM_BUG on boot in set_pfnblock_flags_mask
Hi all, I've decided to try and put more effort into testing on physical machines, but couldn't even get the box to boot :( [0.00] page:ea04 count:0 mapcount:1 mapping: (null) index:0x0 [0.00] flags: 0x0() [0.00] page dumped because: VM_BUG_ON_PAGE(!zone_spans_pfn(zone, pfn)) PANIC: early exception 06 rip 10:8135d20f error 0 cr2 88407000 [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.0-rc1-next-20150501+ #1 [0.00] Hardware name: Oracle Corporation OVCA X3-2 /ASSY,MOTHERBOARD,1U , BIOS 17021300 06/19/2012 [0.00] 115170652258be86 82e077c0 8267b3f8 [0.00] 0007 1000 82e078b8 831a11b0 [0.00] 29296e6670202c65 6e6f7a286e66705f 6e6f7a2128454741 [0.00] Call Trace: [0.00] dump_stack (lib/dump_stack.c:52) [0.00] early_idt_handler (arch/x86/kernel/head_64.S:393) [0.00] set_pageblock_migratetype (mm/page_alloc.c:317) [0.00] memmap_init_zone (include/linux/mm.h:858 include/linux/mm.h:871 mm/page_alloc.c:862 mm/page_alloc.c:4553) [0.00] free_area_init_node (mm/page_alloc.c:5300 mm/page_alloc.c:5374) [0.00] free_area_init_nodes (mm/page_alloc.c:5765) [0.00] zone_sizes_init (arch/x86/mm/init.c:716) [0.00] paging_init (arch/x86/mm/init_64.c:665) [0.00] setup_arch (arch/x86/kernel/setup.c:1183) [0.00] start_kernel (include/linux/bitmap.h:187 include/linux/cpumask.h:342 include/linux/mm_types.h:476 init/main.c:524) [0.00] x86_64_start_reservations (arch/x86/kernel/head64.c:198) [0.00] x86_64_start_kernel (arch/x86/kernel/head64.c:187) Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 9/9] zram: add dynamic device add/remove functionality
On Mon, May 04, 2015 at 11:20:08AM +0900, Minchan Kim wrote: > Hello Sergey, > > On Thu, Apr 30, 2015 at 03:51:12PM +0900, Sergey Senozhatsky wrote: > > On (04/30/15 15:44), Minchan Kim wrote: > > > > > I think the problem of deadlock is that you are trying to remove > > > > > sysfs file > > > > > in sysfs handler. > > > > > > > > > > #> echo 1 > /sys/xxx/zram_remove > > > > > > > > > > kernfs_fop_write - hold s_active > > > > > -> zram_remove_store > > > > > -> zram_remove > > > > > -> sysfs_remove_group - hold s_active *again* > > > > > > > > > > Right? > > > > > > > > > > > > > are those same s_active locks? > > > > > > > > > > > > we hold (s_active#163) and (>bd_mutex) and want to acquire > > > > (s_active#162) > > > > > > Thanks for sharing the message. > > > You're right. It's another lock so it shouldn't be a reason. > > > Okay, I will review it. Please give me time. > > > > > > > sure, no problem and no rush. thanks! > > I had a time to think over it. > > I think your patch is rather tricky so someone cannot see sysfs > although he already opened /dev/zram but after a while he can see sysfs. > It's weired. > > I want to fix it more generic way. Othewise, we might have trouble with > locking problem sometime. We already have experieced it with init_lock > although we finally fixed it. > > I think we can fix it with below patch I hope it's more general and right > approach. It's based on your [zram: return zram device_id from zram_add()] > > What do you think about? > > From e943df5407b880f9262ef959b270226fdc81bc9f Mon Sep 17 00:00:00 2001 > From: Minchan Kim > Date: Mon, 4 May 2015 08:36:07 +0900 > Subject: [PATCH 1/2] zram: close race by open overriding > > [1] introduced bdev->bd_mutex to protect a race between mount > and reset. At that time, we don't have dynamic zram-add/remove > feature so it was okay. > > However, as we introduce dynamic device feature, bd_mutex became > trouble. > > CPU 0 > > echo 1 > /sys/block/zram/reset > -> kernfs->s_active(A) > -> zram:reset_store->bd_mutex(B) > > CPU 1 > > echo > /sys/class/zram/zram-remove > ->zram:zram_remove: bd_mutex(B) > -> sysfs_remove_group > -> kernfs->s_active(A) > > IOW, AB -> BA deadlock > > The reason we are holding bd_mutex for zram_remove is to prevent > any incoming open /dev/zram[0-9]. Otherwise, we could remove zram > others already have opened. But it causes above deadlock problem. > > To fix the problem, this patch overrides block_device.open and > it returns -EBUSY if zram asserts he claims zram to reset so any > incoming open will be failed so we don't need to hold bd_mutex > for zram_remove ayn more. > > This patch is to prepare for zram-add/remove feature. > > [1] ba6b17: zram: fix umount-reset_store-mount race condition > Signed-off-by: Minchan Kim If above has no problem, we could apply your last patch on top of it. >From 5bfa8a2e312a9c8493f574b1cf513ef4693a465c Mon Sep 17 00:00:00 2001 From: Sergey Senozhatsky Date: Mon, 4 May 2015 09:02:23 +0900 Subject: [PATCH 2/2] zram: add dynamic device add/remove functionality We currently don't support on-demand device creation. The one and only way to have N zram devices is to specify num_devices module parameter (default value: 1). IOW if, for some reason, at some point, user wants to have N + 1 devies he/she must umount all the existing devices, unload the module, load the module passing num_devices equals to N + 1. And do this again, if needed. This patch introduces zram control sysfs class, which has two sysfs attrs: - zram_add -- add a new zram device - zram_remove -- remove a specific (device_id) zram device zram_add sysfs attr is read-only and has only automatic device id assignment mode (as requested by Minchan Kim). read operation performed on this attr creates a new zram device and returns back its device_id or error status. Usage example: # add a new specific zram device cat /sys/class/zram-control/zram_add 2 # remove a specific zram device echo 4 > /sys/class/zram-control/zram_remove Returning zram_add() error code back to user (-ENOMEM in this case) cat /sys/class/zram-control/zram_add cat: /sys/class/zram-control/zram_add: Cannot allocate memory NOTE, there might be users who already depend on the fact that at least zram0 device gets always created by zram_init(). Preserve this behavior. [minchan]: use zram->claim to avoid lockdep splat Reported-by: Minchan Kim Signed-off-by: Sergey Senozhatsky --- Documentation/blockdev/zram.txt | 23 -- drivers/block/zram/zram_drv.c | 97 +++-- 2 files changed, 114 insertions(+), 6 deletions(-) diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt index 65e9430..fc686d4 100644 --- a/Documentation/blockdev/zram.txt +++ b/Documentation/blockdev/zram.txt @@ -99,7 +99,24 @@ size of the disk when not in use so a huge zram
Re: [PATCH] xen: vcpu_info reinit error after 'xl save -c' & 'xl restore' on PVOPS VM which has multi-cpu
On 2015.5.2 2:55, Boris Ostrovsky wrote:
> On 04/30/2015 03:27 AM, Ouyang Zhaowei (Charles) wrote:
>>
>> On 2015.4.29 5:31, Boris Ostrovsky wrote:
>>> On 04/28/2015 08:30 AM, Ouyang Zhaowei (Charles) wrote:
On 2015.4.26 7:31, Boris Ostrovsky wrote:
> On 04/24/2015 05:30 AM, Ouyang Zhaowei (Charles) wrote:
>> If a PVOPS VM has multi-cpu the vcpu_info of cpu0 is the member of the
>> structure HYPERVISOR_shared_info,
>> and the others is not, but after 'xl save -c/restore' the vcpu_info will
>> be reinitialized,
>> the vcpu_info of all the vcpus will be considered as the member of
>> HYPERVISOR_shared_info.
>> This will cause the cpu1 and other cpu keep receiving interrupts, and
>> the cpu0 is waiting them to
>> finish the job.
>> So we do not reinit the vcpu_info when PVOPS vm is doing 'xl save
>> -c/restore'.
>>
>> Signed-off-by: Charles Ouyang
>> ---
>> arch/x86/xen/suspend.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
>> index d949769..b2bed45 100644
>> --- a/arch/x86/xen/suspend.c
>> +++ b/arch/x86/xen/suspend.c
>> @@ -32,7 +32,8 @@ static void xen_hvm_post_suspend(int suspend_cancelled)
>> {
>> #ifdef CONFIG_XEN_PVHVM
>>int cpu;
>> - xen_hvm_init_shared_info();
>> + if (!suspend_cancelled)
>> + xen_hvm_init_shared_info();
>>xen_callback_vector();
>>xen_unplug_emulated_devices();
>>if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
> Do we need to call other routines if suspend is canceled?
>
> Also, if suspend is canceled then we don't do xen_irq_resume() if that's
> what you meant by "vcpu_info will be reinitialized". Were you referring
> some other re-initialization?
>
Hi Boris,
Sorry I didn't make myself clear.
About the "vcpu_info reinitialize", I mean in the function
"xen_hvm_init_shared_info()" the pointer "xen_vcpu" will be reset and all
point to HYPERVISOR_shared_info->vcpu_info[cpu].
void __ref xen_hvm_init_shared_info(void)
1702 * When xen_hvm_init_shared_info is run at boot time only
vcpu 0 is
1703 * online but xen_hvm_init_shared_info is run at resume time
too and
1704 * in that case multiple vcpus might be online. */
1705 for_each_online_cpu(cpu) {
1706 /* Leave it to be NULL. */
1707 if (cpu >= MAX_VIRT_CPUS)
1708 continue;
1709 per_cpu(xen_vcpu, cpu) =
_shared_info->vcpu_info[cpu];
1710 }
1711 }
But on Xen boot the init function "xen_start_kernel" only set the cpu0 to
point to HYPERVISOR_shared_info->vcpu_info[0]
asmlinkage __visible void __init xen_start_kernel(void)
>>>
>>> We are talking about HVM guests here and xen_start_kernel is only called
>>> for PV. But even if it was, xen_vcpu pointers for other VCPUs are set in
>>> xen_vcpu_setup(), which is called when non-boot VCPUs are coming up.
>>>
>>> And I wonder whether the actual problem is that we don't call
>>> xen_vcpu_setup() on canceled suspend (as we don't need to, really) and
>>> therefore if we call xen_hvm_init_shared_info() then per_cpu(xen_vcpu,cpu)
>>> for *non-boot* cpus is will become wrong.
>>>
>> Yes, you are right, in xen_vcpu_setup() non-boot VCPUs is set to point to
>> xen_vcpu_info
>>
>> static void xen_vcpu_setup(int cpu)
>>
>> 208 vcpup = _cpu(xen_vcpu_info, cpu);
>> ...
>> 227 /* This cpu is using the registered vcpu info, even if
>> 228later ones fail to. */
>> 229 per_cpu(xen_vcpu, cpu) = vcpup;
>>
>> But on canceled suspend if we call xen_hvm_init_shared_info(), the non-boot
>> VCPUS will be reset to point to HYPERVISOR_shared_info->vcpu_info[cpu] which
>> is a wrong address.
>> So I suggest we don't call xen_hvm_init_shared_info() when suspend is
>> canceled.
>
>
> Right, so can you resubmit the patch with updated commit message? (Just note
> there that the hypervisor continues assuming that vcpu_info is stored in
> per-cpu data which was set up by xen_vcpu_setup(), while the call to
> xen_hvm_init_shared_info() will now make the guest think that vcpu_info is in
> the shared page).
>
> Thanks.
> -boris
OK, Thank for the advise, I'll resend the patch now
>
>>
>>> -boris
>>>
1563 /* Don't do the full vcpu_info placement stuff until we have a
1564possible map and a non-dummy shared_info. */
1565 per_cpu(xen_vcpu, 0) = _shared_info->vcpu_info[0];
1566
1567 local_irq_disable();
Other cpus are set to point to "xen_vcpu_info" in function
Re: [PATCHv3 9/9] zram: add dynamic device add/remove functionality
Hello Sergey,
On Thu, Apr 30, 2015 at 03:51:12PM +0900, Sergey Senozhatsky wrote:
> On (04/30/15 15:44), Minchan Kim wrote:
> > > > I think the problem of deadlock is that you are trying to remove sysfs
> > > > file
> > > > in sysfs handler.
> > > >
> > > > #> echo 1 > /sys/xxx/zram_remove
> > > >
> > > > kernfs_fop_write - hold s_active
> > > > -> zram_remove_store
> > > > -> zram_remove
> > > > -> sysfs_remove_group - hold s_active *again*
> > > >
> > > > Right?
> > > >
> > >
> > > are those same s_active locks?
> > >
> > >
> > > we hold (s_active#163) and (>bd_mutex) and want to acquire
> > > (s_active#162)
> >
> > Thanks for sharing the message.
> > You're right. It's another lock so it shouldn't be a reason.
> > Okay, I will review it. Please give me time.
> >
>
> sure, no problem and no rush. thanks!
I had a time to think over it.
I think your patch is rather tricky so someone cannot see sysfs
although he already opened /dev/zram but after a while he can see sysfs.
It's weired.
I want to fix it more generic way. Othewise, we might have trouble with
locking problem sometime. We already have experieced it with init_lock
although we finally fixed it.
I think we can fix it with below patch I hope it's more general and right
approach. It's based on your [zram: return zram device_id from zram_add()]
What do you think about?
>From e943df5407b880f9262ef959b270226fdc81bc9f Mon Sep 17 00:00:00 2001
From: Minchan Kim
Date: Mon, 4 May 2015 08:36:07 +0900
Subject: [PATCH 1/2] zram: close race by open overriding
[1] introduced bdev->bd_mutex to protect a race between mount
and reset. At that time, we don't have dynamic zram-add/remove
feature so it was okay.
However, as we introduce dynamic device feature, bd_mutex became
trouble.
CPU 0
echo 1 > /sys/block/zram/reset
-> kernfs->s_active(A)
-> zram:reset_store->bd_mutex(B)
CPU 1
echo > /sys/class/zram/zram-remove
->zram:zram_remove: bd_mutex(B)
-> sysfs_remove_group
-> kernfs->s_active(A)
IOW, AB -> BA deadlock
The reason we are holding bd_mutex for zram_remove is to prevent
any incoming open /dev/zram[0-9]. Otherwise, we could remove zram
others already have opened. But it causes above deadlock problem.
To fix the problem, this patch overrides block_device.open and
it returns -EBUSY if zram asserts he claims zram to reset so any
incoming open will be failed so we don't need to hold bd_mutex
for zram_remove ayn more.
This patch is to prepare for zram-add/remove feature.
[1] ba6b17: zram: fix umount-reset_store-mount race condition
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 42 --
drivers/block/zram/zram_drv.h | 4
2 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 3df4394..7fb72dc 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1074,13 +1074,6 @@ static ssize_t reset_store(struct device *dev,
if (!bdev)
return -ENOMEM;
- mutex_lock(>bd_mutex);
- /* Do not reset an active device! */
- if (bdev->bd_openers) {
- ret = -EBUSY;
- goto out;
- }
-
ret = kstrtou16(buf, 10, _reset);
if (ret)
goto out;
@@ -1090,23 +1083,52 @@ static ssize_t reset_store(struct device *dev,
goto out;
}
+ mutex_lock(>bd_mutex);
+ /* Do not reset an active device or claimed device */
+ if (bdev->bd_openers || zram->claim) {
+ ret = -EBUSY;
+ mutex_unlock(>bd_mutex);
+ goto out;
+ }
+
+ /* From now on, anyone can't open /dev/zram[0-9] */
+ zram->claim = true;
+ mutex_unlock(>bd_mutex);
+
/* Make sure all pending I/O is finished */
fsync_bdev(bdev);
zram_reset_device(zram);
- mutex_unlock(>bd_mutex);
revalidate_disk(zram->disk);
bdput(bdev);
- return len;
+ mutex_lock(>bd_mutex);
+ zram->claim = false;
+ mutex_unlock(>bd_mutex);
+ return len;
out:
- mutex_unlock(>bd_mutex);
bdput(bdev);
return ret;
}
+static int zram_open(struct block_device *bdev, fmode_t mode)
+{
+ int ret = 0;
+ struct zram *zram;
+
+ WARN_ON(!mutex_is_locked(>bd_mutex));
+
+ zram = bdev->bd_disk->private_data;
+ /* zram was claimed to reset so open request fails */
+ if (zram->claim)
+ ret = -EBUSY;
+
+ return ret;
+}
+
static const struct block_device_operations zram_devops = {
+ .open = zram_open,
.swap_slot_free_notify = zram_slot_free_notify,
.rw_page = zram_rw_page,
.owner = THIS_MODULE
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index 042994e..6dbe2df 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
[PATCH 0/2] x86/quark: Add eSRAM driver and test code
Quark X1000 SoC contains a 512 KiB embedded SRAM (eSRAM) memory that can be mapped onto an area of DRAM in block or on per-page overlay mode where a 4 KiB aligned region can be overlayed - allowing for broken up mappings with a 4 KiB individual granularity. eSRAM has access times similar to an L1 cache. The following patchset adds a gen_pool driver and automatic test routine to exercise eSRAM. The intent of the eSRAM driver is to allow other drivers to allocate SRAM buffers. In contrast to the original BSP code no attempt will be made to map kernel .data section code, this is a simple SRAM buffer allocation/free mechanism and a sanity test to ensure it's ongoing correctness. Bryan O'Donoghue (2): x86/quark: Add Quark embedded SRAM support x86/quark: Add Quark embedded SRAM self-test arch/x86/Kconfig.debug | 13 + arch/x86/include/asm/esram.h | 66 arch/x86/platform/intel-quark/Makefile | 2 + arch/x86/platform/intel-quark/esram.c | 502 + arch/x86/platform/intel-quark/esram_selftest.c | 159 drivers/platform/x86/Kconfig | 17 +- 6 files changed, 758 insertions(+), 1 deletion(-) create mode 100644 arch/x86/include/asm/esram.h create mode 100644 arch/x86/platform/intel-quark/esram.c create mode 100644 arch/x86/platform/intel-quark/esram_selftest.c -- 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 2/2] x86/quark: Add Quark embedded SRAM self-test
Quark X1000 contains an embedded SRAM (eSRAM) a fast access SRAM. This code
is a self-test routine to measure the performance of that SRAM for
different read-values. The tests are designed the performance gains
provided by eSRAM using different read-sizes and comparing the performance
of eSRAM overlayed DRAM to raw DRAM.
Signed-off-by: Bryan O'Donoghue
---
arch/x86/Kconfig.debug | 13 ++
arch/x86/platform/intel-quark/Makefile | 1 +
arch/x86/platform/intel-quark/esram_selftest.c | 159 +
3 files changed, 173 insertions(+)
create mode 100644 arch/x86/platform/intel-quark/esram_selftest.c
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 72484a6..bb62174 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -322,6 +322,19 @@ config DEBUG_IMR_SELFTEST
If unsure say N here.
+config DEBUG_ESRAM_SELFTEST
+ bool "Embedded SRAM self test"
+ default n
+ depends on INTEL_ESRAM
+ ---help---
+ This option enables automated sanity testing of the eSRAM driver
+ on Quark X1000. A simple set of tests with performance metrics
+ measured a DRAM baseline are run. These tests show the measured
+ performance increase across a given memory size for a series of
+ incrementing read sizes.
+
+ If unsure say N here.
+
config X86_DEBUG_STATIC_CPU_HAS
bool "Debug alternatives"
depends on DEBUG_KERNEL
diff --git a/arch/x86/platform/intel-quark/Makefile
b/arch/x86/platform/intel-quark/Makefile
index 94adb0b..dc466be 100644
--- a/arch/x86/platform/intel-quark/Makefile
+++ b/arch/x86/platform/intel-quark/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_INTEL_IMR) += imr.o
obj-$(CONFIG_INTEL_ESRAM) += esram.o
obj-$(CONFIG_DEBUG_IMR_SELFTEST) += imr_selftest.o
+obj-$(CONFIG_DEBUG_ESRAM_SELFTEST) += esram_selftest.o
diff --git a/arch/x86/platform/intel-quark/esram_selftest.c
b/arch/x86/platform/intel-quark/esram_selftest.c
new file mode 100644
index 000..7849dac
--- /dev/null
+++ b/arch/x86/platform/intel-quark/esram_selftest.c
@@ -0,0 +1,159 @@
+/**
+ * esram_selftest.c
+ *
+ * Copyright(c) 2015 Bryan O'Donoghue
+ *
+ * IMR self test. The purpose of this module is to run a set of tests on the
+ * IMR API to validate it's sanity. We check for overlapping, reserved
+ * addresses and setup/teardown sanity.
+ *
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * esram_self_test_time
+ *
+ * This function is carefully constructed to measure and verify the
+ * performance boost provided by eSRAM. We invalidate the cache with a
+ * wbinvd() and then perform a series of reads - each of which will cause a
+ * cacheline miss. We measure the aggregate time it takes to complete the
+ * series of reads and return the delta in cycles. The calling function will
+ * pass either a pointer to DRAM or a pointer to eSRAM.
+ *
+ * @param walker: Pointer to RAM area to test.
+ * @return:Number of cycles to complete test.
+ */
+static cycles_t esram_self_test_time(char *walker, ssize_t step, ssize_t size)
+{
+ volatile u32 dummy = 0;
+ int i;
+ int j;
+ cycle_t t1;
+ cycle_t t2;
+ u32 page_count = size / PAGE_SIZE;
+
+ local_irq_disable();
+ t1 = get_cycles();
+ for (i = 0; i < page_count; i++) {
+ for (j = 0; j < PAGE_SIZE/step; j++) {
+ dummy += *(u32 *)walker;
+ walker += step;
+ }
+ }
+ t2 = get_cycles();
+ local_irq_enable();
+
+ return t2 > t1 ? t2 - t1 : ULLONG_MAX - t2 + t1;
+}
+
+/**
+ * __get_percent - the the percentage that min is of max.
+ *
+ * @max: The larger value.
+ * @min: The smaller value.
+ * @return:The % of the max that the min is.
+*/
+static inline u32 __get_percent(u32 max, u32 min)
+{
+ max = max/100UL;
+ return 100UL - (min/max);
+}
+
+/**
+ * esram_self_test
+ *
+ * Verify eSRAM self_test with some simple tests to verify overlap,
+ * zero sized allocations and 1 KiB sized areas.
+ *
+ * return:
+ */
+static void __init esram_self_test(void)
+{
+ bool pass;
+ size_t size = SZ_512K;
+ cycles_t t1;
+ cycles_t t2;
+ u32 percent;
+ char *dram_mem;
+ unsigned long esram_mem;
+ int i;
+ struct gen_pool *pool = esram_get_genpool();
+ size_t steps[] = { 8, 16, 32, 64, 128 };
+
+ if (pool == NULL) {
+ pr_err("unable to get esram_genpool pointer!\n");
+ return;
+ }
+
+ esram_mem = gen_pool_alloc(pool, size);
+ if (esram_mem == 0) {
+ pr_err("gen_pool_alloc of %d KiB fail!\n", size);
+ return;
+ }
+ dram_mem = kzalloc(GFP_KERNEL, size);
+ if (dram_mem == NULL)
+ goto err;
+
+ /* Cycle
[PATCH 1/2] x86/quark: Add Quark embedded SRAM support
Quark X1000 ships with 512 KiB of embedded SRAM (eSRAM) a low-latency memory with access times similar to an L1 cache. eSRAM is used during the initial bootstrap phases of EFI firmware, this driver provides a gen_pool interface to eSRAM to allow drivers to make use of eSRAM for fast-access buffers. eSRAM can be configured in two flavours - block mode or in per-page overlay mode. Per-page overlay mode is more interesting in that it allows overlay of any valid RAM address by eSRAM with a granularity of 4 KiB. This driver overlays a kzalloc() provided contiguous memory region in 4 KiB increments. On a read-access to an overlayed region of DRAM data will be fetched from eSRAM as opposed to DRAM - thus mitigating CAS/RAS latencies associated with DRAM and allowing DRAM to continue in a lower-power state rather than service the data access directly. On a cache miss the cacheline fetch will be roughly 20% faster than fetching from DRAM on average. Once the cacheline has been populated the processor operates from the L1 cache so no further performance boost will be observed. A follow-on patch provides an eSRAM performance test that illustrates the performance boost for varying sizes of read operation. Signed-off-by: Bryan O'Donoghue --- arch/x86/include/asm/esram.h | 66 + arch/x86/platform/intel-quark/Makefile | 1 + arch/x86/platform/intel-quark/esram.c | 502 + drivers/platform/x86/Kconfig | 17 +- 4 files changed, 585 insertions(+), 1 deletion(-) create mode 100644 arch/x86/include/asm/esram.h create mode 100644 arch/x86/platform/intel-quark/esram.c diff --git a/arch/x86/include/asm/esram.h b/arch/x86/include/asm/esram.h new file mode 100644 index 000..9932862 --- /dev/null +++ b/arch/x86/include/asm/esram.h @@ -0,0 +1,66 @@ +/* + * esram.h: Embedded SRAM (eSRAM) + * + * Copyright(c) 2013 Intel Corporation. + * Copyright(c) 2015 Bryan O'Donoghue + * + * 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; version 2 + * of the License. + * + * See 329676_QuarkDatasheet.pdf for register bitmap details. + */ + +#ifndef __ESRAM_H__ +#define __ESRAM_H__ + +#include + +/* eSRAM registers */ +#define ESRAMCTRL_REG 0x81 +#define ESRAMPGBLOCK_REG 0x82 +#define ESRAMCERR_REG 0x83 +#define ESRAMUCERR_REG 0x84 +#define ESRAMSDROM_REG 0x88 + +/* eSRAM Control - Offset 0x81 - Section 12.7.4.37 */ +#define ESRAMCTRL_SIZE(x) (PAGE_SIZE * (((x >> 16) & 0x7F) + 1)) +#define ESRAMCTRL_ECCTHRESH(x) ((x >> 8) & 0xFF) +#define ESRAMCTRL_THRESHMSG_EN BIT(7) +#define ESRAMCTRL_AVAILABLEBIT(4) +#define ESRAMCTRL_ENABLE_ALL BIT(3) +#define ESRAMCTRL_GLOBAL_CSR_LOCK BIT(2) +#define ESRAMCTRL_SECDEC_ENBIT(0) + +/* eSRAM Page Block Control - Offset 0x82 - Section 12.7.4.38 */ +#define ESRAMPGBLOCK_FLUSH_EN BIT(31) +#define ESRAMPGBLOCK_DIS BIT(29) +#define ESRAMPGBLOCK_ENBIT(28) +#define ESRAMPGBLOCK_CSR_LOCK BIT(27) +#define ESRAMPGBLOCK_INIT BIT(26) +#define ESRAMPGBLOCK_BUSY BIT(24) +#define ESRAMPGBLOCK_BASE(x) ((x & 0xFF) << 24) + +/* eSRAM Correctable Error - Offset 0x83 - Section 12.7.4.39 */ +#define ESRAMCERR_ERR_CNT_RST BIT(25) +#define ESRAMCERR_ERR_CNT(x) ((x >> 17) & 0xFF) +#define ESRAMCERR_ERR_PG_DW_OFFSET(x) ((x >> 9) & 0x7F) +#define ESRAMCERR_ERR_PG_NUM(x)(x & 0xFF) + +/* eSRAM Uncorrectable Error - Offset 0x84 - Section 12.7.4.40 */ +#define ESRAMUCERR_ERR_CNT(x) ((x >> 17) & 0xFF) +#define ESRAMUCERR_ERR_PG_DW_OFFSET(x) ((x >> 9) & 0x7F) +#define ESRAMUCERR_ERR_PG_NUM(x) (x & 0xFF) + +/* eSRAM Page Control - Offsets 0-127 - Section 12.7.5.1 */ +#define ESRAMPGCTRL_FLUSH_PAGE_EN BIT(31) +#define ESRAMPGCTRL_EN BIT(28) +#define ESRAMPGCTRL_LOCK BIT(27) +#define ESRAMPGCTRL_INIT_IN_PROG BIT(26) +#define ESRAMPGCTRL_BUSY BIT(24) + +struct gen_pool *esram_get_genpool(void); + +#endif /* __ESRAM_H__ */ + diff --git a/arch/x86/platform/intel-quark/Makefile b/arch/x86/platform/intel-quark/Makefile index 9cc57ed..94adb0b 100644 --- a/arch/x86/platform/intel-quark/Makefile +++ b/arch/x86/platform/intel-quark/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_INTEL_IMR) += imr.o +obj-$(CONFIG_INTEL_ESRAM) += esram.o obj-$(CONFIG_DEBUG_IMR_SELFTEST) += imr_selftest.o diff --git a/arch/x86/platform/intel-quark/esram.c b/arch/x86/platform/intel-quark/esram.c new file mode 100644 index 000..51390c3 --- /dev/null +++ b/arch/x86/platform/intel-quark/esram.c @@ -0,0 +1,502 @@ +/* + * Copyright(c) 2013 Intel Corporation. + * Copyright(c) 2015 Bryan O'Donoghue + * + * Embedded SRAM (eSRAM) is an on-die
Re: [RESEND RFC PATCH 1/3] ASoC: mediatek: Add binding support for AFE driver
On Thu, 2015-04-30 at 21:12 +0100, Mark Brown wrote: > On Wed, Apr 22, 2015 at 11:17:20AM +0800, Koro Chen wrote: > > > If using DPCM, it seems the most suitable FE DAIs will be memif, and > > external interface like I2S should be BE DAIs. Do you think it is > > suitable for our memif to be FE DAIs? Then which memif to used can be > > described in a machine driver's FE DAIs. But I think this has a problem > > that our memif is one-direction, playback or capture. So the binded pcm > > device cannot have playback and capture capability together. May it > > cause trouble for user space apps that assumes there will be pcmC0D0p, > > pcmC0D0c? > > I think the only userspace application you really have to worry about > here is PulseAudio which (at least with UCM) should be able to cope > since it needs to handle things like USB microphones. I think > everything else I can think of can either cope or has to handle the same > use cases as PulseAudio does so should have support. Thank you very much for the feedback, I will try DPCM. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/8] clk: tegra: Fix inconsistent indenting
On 02.05.2015 03:46, Stephen Boyd wrote: On 04/28, Krzysztof Kozlowski wrote: Fix the indentation - spaces used instead of tabs and actually wrong number of spaces. Signed-off-by: Krzysztof Kozlowski --- drivers/clk/tegra/clk-emc.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) What branch is this against? I don't see this in linux-next or clk-next. It was rebased on next-20150427. But now I cannot find it in newer next... Could you skip these two patches then? Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MODSIGN: Change default key details [ver #2]
On Sat, May 2, 2015 at 2:46 AM, Abelardo Ricart III wrote: > endif > > -signing_key.priv signing_key.x509: x509.genkey > +signing_key.priv signing_key.x509: | x509.genkey Hmm. Thinking some more about this, I'm not entirely convinced. With this change, if we change kernel/Makefile to have a different keysigning authority etc, it won't re-generate the keys, because the old keys still exist. No? That would be wrong. I'd much rather see "x509.genkey" be generated with a move-if-changed pattern, so that it only changes if (a) it didn't exist before or (b) it actually has new content. On a tangentially related issue: I figured out why I get those (very annoying) "X.509 certificate list changed" messages. I made it print out *what* changed: X.509 certificate list changed from ./signing_key.x509 to signing_key.x509 Note the "./" difference. 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/
[GIT PULL] ext4 changes for 4.1-rc2
The following changes since commit 6ddb2447846a8ece111e316a2863c2355023682d: ext4 crypto: enable encryption feature flag (2015-04-16 01:56:00 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/for_linus_stable for you to fetch changes up to 2c869b262a10ca99cb866d04087d75311587a30c: ext4: fix growing of tiny filesystems (2015-05-02 23:58:32 -0400) Some miscellaneous bug fixes and some final on-disk and ABI changes for ext4 encryption which provide better security and performance. Chanho Park (1): ext4 crypto: remove duplicated encryption mode definitions Davide Italiano (1): ext4: move check under lock scope to close a race. Herbert Xu (1): ext4 crypto: do not select from EXT4_FS_ENCRYPTION Jan Kara (1): ext4: fix growing of tiny filesystems Lukas Czerner (1): ext4: fix data corruption caused by unwritten and delayed extents Theodore Ts'o (2): ext4 crypto: simplify and speed up filename encryption ext4 crypto: add padding to filenames before encrypting fs/ext4/Kconfig | 9 ++- fs/ext4/crypto_fname.c | 280 +++ fs/ext4/crypto_key.c | 1 + fs/ext4/crypto_policy.c | 14 ++-- fs/ext4/dir.c| 2 +- fs/ext4/ext4.h | 16 ++--- fs/ext4/ext4_crypto.h| 11 ++- fs/ext4/extents.c| 15 ++-- fs/ext4/extents_status.c | 8 +++ fs/ext4/inode.c | 2 + fs/ext4/namei.c | 72 ++-- fs/ext4/resize.c | 7 +- fs/ext4/symlink.c| 2 +- 13 files changed, 210 insertions(+), 229 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/3] iio: derive the mounting matrix from ACPI _PLD objects
Hi Octavian, On 04/27/2015 07:23 PM, Octavian Purdila wrote: On Tue, Apr 28, 2015 at 12:57 AM, sathyanarayanan kuppuswamy wrote: Hi On 04/27/2015 08:54 AM, Octavian Purdila wrote: On Mon, Apr 27, 2015 at 6:42 PM, Kuppuswamy Sathyanarayanan wrote: Since Acpi framework already exports this info to user space, Why not do this derivation in user space code ? Why do we need new ABI, if the same can be derived from existing one. The ABI was added in the previous patch so that we can present the sensor orientation information to userspace even in the case of device tree. If the main reason for implementing a new ABI is to support DT platforms, Why not implement a version of _PLD for device tree ? Don't you think it would be much better than adding a new ABI to export redundant information ? IMO the mounting matrix is more consistent with the IIO ABIs. Although I have no issue with repicating _PLD for device tree if people agree that it is better. Since your main issue is, device tree lacking ABI to specify location information, you should consider fixing it there. Let's wait for others comment on this. If you think mounting matrix provides more information than what is supported by _PLD, then we should consider implementing another ABI. AFAIK, that is not the case here. Adding adding a new ABI to represent the information that can be derived from existing ABI does not seem to be useful. Also the location information of the device is not just specific to iio drivers. You should consider that we would have similar requirements for devices implemented as input or platform drivers. The upstream standard for those sensors where the orientation matters (accelerometer, gyro, compass) is IIO. Granted, there are other device types for which the orientation information may be useful (e.g. camera). However the actual interpretation and action to be taken is different for each subsystem (e.g. in the camera case do the correction via V4L2_CID_HFLIP / V4L2_CID_VFLIP) so I think it is better to expose it at the subsystem level in a way consistent with the subsystem's ABIs. I agree that location information is used differently at different sub systems. But my question is why we need a new ABI ? Why not handle it in user space ? -- -- Sathyanarayanan KN Android Kernel Developer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: Relax a restriction in sched_rt_can_attach()
It's allowed to promote a task from normal to realtime after it has been
attached to a non-root cgroup, but it will fail if the attaching happens
after it has become realtime. I don't see how this restriction is useful.
We are moving toward unified hierarchy where all the cgroup controllers
are bound together, so it would make cgroups easier to use if we have less
restrictions on attaching tasks between cgroups.
Signed-off-by: Zefan Li
---
kernel/sched/core.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index fe22f75..55c21f7 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7800,6 +7800,11 @@ static int sched_rt_global_constraints(void)
return ret;
}
+
+static int sched_rt_can_attach(struct task_group *tg, struct task_struct *tsk)
+{
+ return 1;
+}
#endif /* CONFIG_RT_GROUP_SCHED */
static int sched_dl_global_validate(void)
@@ -8002,16 +8007,9 @@ static int cpu_cgroup_can_attach(struct
cgroup_subsys_state *css,
{
struct task_struct *task;
- cgroup_taskset_for_each(task, tset) {
-#ifdef CONFIG_RT_GROUP_SCHED
+ cgroup_taskset_for_each(task, tset)
if (!sched_rt_can_attach(css_tg(css), task))
return -EINVAL;
-#else
- /* We don't support RT-tasks being in separate groups */
- if (task->sched_class != _sched_class)
- return -EINVAL;
-#endif
- }
return 0;
}
--
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][RT] xfs: Disable preemption when grabbing all icsb counter locks
On Thu, Apr 30, 2015 at 12:33:03PM -0400, Steven Rostedt wrote:
> Running a test on a large CPU count box with xfs, I hit a live lock
> with the following backtraces on several CPUs:
>
> Call Trace:
> [] __const_udelay+0x28/0x30
> [] xfs_icsb_lock_cntr+0x2a/0x40 [xfs]
> [] xfs_icsb_modify_counters+0x71/0x280 [xfs]
> [] xfs_trans_reserve+0x171/0x210 [xfs]
> [] xfs_create+0x24d/0x6f0 [xfs]
> [] ? avc_has_perm_flags+0xfb/0x1e0
> [] xfs_vn_mknod+0xbb/0x1e0 [xfs]
> [] xfs_vn_create+0x13/0x20 [xfs]
> [] vfs_create+0xcd/0x130
> [] do_last+0xb8f/0x1240
> [] path_openat+0xc2/0x490
>
> Looking at the code I see it was stuck at:
>
> STATIC void
> xfs_icsb_lock_cntr(
> xfs_icsb_cnts_t *icsbp)
> {
> while (test_and_set_bit(XFS_ICSB_FLAG_LOCK, >icsb_flags)) {
> ndelay(1000);
> }
> }
>
> I'm not sure why it does the ndelay() and not just a cpu_relax(), but
Because the code was writtenlong before cpu_relax() existed, just
like it was written long before the generic percpu counter code was
added...
> Now, when PREEMPT_RT is not enabled, that spin_lock() disables
> preemption. But for PREEMPT_RT, it does not. Although with my test box I
> was not able to produce a task state of all tasks, but I'm assuming that
> some task called the xfs_icsb_lock_all_counters() and was preempted by
> an RT task and could not finish, causing all callers of that lock to
> block indefinitely.
>
> Looking at all users of xfs_icsb_lock_all_counters(), they are leaf
> functions and do not call anything that may block on PREEMPT_RT. I
> believe the proper fix here is to simply disable preemption in
> xfs_icsb_lock_all_counters() when PREEMPT_RT is enabled.
RT is going to have other performance problems that are probably
going to negate the scalability this code provides. If you want a
hack that you can easily backport (as this code now uses the generic
percpu counters) then have a look at fs/xfs/xfs_linux.h:
/*
* Feature macros (disable/enable)
*/
#ifdef CONFIG_SMP
#define HAVE_PERCPU_SB /* per cpu superblock counters are a 2.6 feature */
#else
#undef HAVE_PERCPU_SB /* per cpu superblock counters are a 2.6 feature */
#endif
You can turn off all that per-cpu code simply by:
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) && !defined(CONFIG_PREEMPT_RT)
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.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: [LKP] [fanotify] 66ba93c0d7f: i6300esb: Unexpected close, not stopping watchdog!
Hi, Andrew,
Sorry for late. I am in vacation in last week.
On Fri, 2015-04-24 at 10:42 -0700, Andrew Morton wrote:
> On Thu, 23 Apr 2015 14:25:38 +0800 Huang Ying wrote:
>
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > commit 66ba93c0d7fe63def447ad0afe380307ff9ebcad ("fanotify: don't set
> > FAN_ONDIR implicitly on a marks ignored mask")
> >
> > When doing LTP test. Test system hang after doing some fanotify test
> > cases, while system
> > can run to reboot in the parent comments.
>
> Thanks. I've queued a reversion patch. I'll hold off sending it to
> Linus for a while, to see if we can get this fixed up.
>
>
> What does "hang" mean? Was the machine all locked up? Or is it the
> case that the particular LTP test failed to complete? I suspect the
> latter - that the new notify behaviour is differing from LTP's
> expectation in some fashion?
Sorry for confusion. The machine was not locked up, just the LTP test
failed to complete.
Best Regards,
Huang, Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] blkcg: remove redundant code in blkcg_css_free()
The check was needed only when we supported modular cgroup subsystem.
Signed-off-by: Zefan Li
---
block/blk-cgroup.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 0ac817b..92b7edd 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -814,9 +814,7 @@ static void blkcg_css_offline(struct cgroup_subsys_state
*css)
static void blkcg_css_free(struct cgroup_subsys_state *css)
{
struct blkcg *blkcg = css_to_blkcg(css);
-
- if (blkcg != _root)
- kfree(blkcg);
+ kfree(blkcg);
}
static struct cgroup_subsys_state *
--
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/mce: fix mce_restart() race with CPU hotplug operation
Borislav, On 2015/5/3 17:37, Borislav Petkov wrote: On Fri, May 01, 2015 at 02:03:48PM +0800, Ethan Zhao wrote: For the record, it is a public secret that CPU hotplug is broken. IOW, you're wasting your time with those senseless pounder tests but ok. :<, Someone else is stressing the CPU hotplug, seems it is fragile. My job is holding the system, not panic to the ground. Please forward my message to that someone else then. The whole world Got it. Thanks, Ethan knows CPU hotplug is fragile and there are people working on improving that. There's no need for you guys to pound on it, we know it is broken. I'm sure you can find a lot other things in the kernel to pound on. Things which make a lot more sense than CPU hotplug. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.0 000/220] 4.0.2-stable review
On 05/02/2015 11:58 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.0.2 release. There are 220 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon May 4 18:58:12 UTC 2015. Anything received after that time might be too late. Build results: total: 125 pass: 123 fail: 2 Failed builds: powerpc:defconfig powerpc:allmodconfig Qemu test results: total: 30 pass: 28 fail: 2 Failed tests: powerpc:ppc64_book3s_defconfig powerpc:ppc64_book3s_smp_defconfig Error log: include/linux/bug.h: Assembler messages: include/linux/bug.h:7: Error: unrecognized opcode: `enum' include/linux/bug.h:8: Error: junk at end of line, first unrecognized character is `,' [ and so on ] Similar to 3.19, bisect points to 'powerpc, jump_label: Include linux/jump_label.h to get HAVE_JUMP_LABEL define'. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.19 000/177] 3.19.7-stable review
On 05/02/2015 12:00 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late. Take two: Build results: total: 125 pass: 112 fail: 13 Failed builds: mips:defconfig mips:allmodconfig mips:bcm47xx_defconfig mips:bcm63xx_defconfig mips:nlm_xlp_defconfig mips:ath79_defconfig mips:ar7_defconfig mips:fuloong2e_defconfig mips:e55_defconfig mips:cavium_octeon_defconfig mips:malta_defconfig powerpc:defconfig powerpc:allmodconfig Qemu test results: total: 30 pass: 22 fail: 8 Failed tests: mips:mips_malta_defconfig mips:mips_malta_smp_defconfig mips:mipsel_malta_defconfig mips:mipsel_malta_smp_defconfig mips64:mips_malta64_defconfig mips64:mips_malta64_smp_defconfig powerpc:ppc64_book3s_defconfig powerpc:ppc64_book3s_smp_defconfig --- Error logs: mips: arch/mips/kernel/unaligned.c: In function 'emulate_load_store_insn': arch/mips/kernel/unaligned.c:570:4: error: expected '}' before 'else' Bisect points to 'MIPS: unaligned: Fix regular load/store instruction emulation for EVA'. --- powerpc: include/linux/bug.h: Assembler messages: include/linux/bug.h:7: Error: unrecognized opcode: `enum' include/linux/bug.h:8: Error: junk at end of line, first unrecognized character is `,' As mentioned earlier, bisect points to 'powerpc, jump_label: Include linux/jump_label.h to get HAVE_JUMP_LABEL define'.'. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 4/4] MAINTAINERS: Add entry for tas571x ASoC codec driver
Add self as maintainer for the new driver. Signed-off-by: Kevin Cernekee --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ea0001760035..15153fc37cc4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9878,6 +9878,12 @@ L: net...@vger.kernel.org S: Maintained F: drivers/net/ethernet/ti/netcp* +TI TAS571X FAMILY ASoC CODEC DRIVER +M: Kevin Cernekee +L: alsa-de...@alsa-project.org (moderated for non-subscribers) +S: Odd Fixes +F: sound/soc/codecs/tas571x* + TI TWL4030 SERIES SOC CODEC DRIVER M: Peter Ujfalusi L: alsa-de...@alsa-project.org (moderated for non-subscribers) -- 2.2.0.rc0.207.ga3a616c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 2/4] ASoC: tas571x: Add DT binding document
Document the bindings for the soon-to-be-added tas571x driver.
Signed-off-by: Kevin Cernekee
---
.../devicetree/bindings/sound/tas571x.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tas571x.txt
diff --git a/Documentation/devicetree/bindings/sound/tas571x.txt
b/Documentation/devicetree/bindings/sound/tas571x.txt
new file mode 100644
index ..0ac31d8d5ac4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas571x.txt
@@ -0,0 +1,41 @@
+Texas Instruments TAS5711/TAS5717/TAS5719 stereo power amplifiers
+
+The codec is controlled through an I2C interface. It also has two other
+signals that can be wired up to GPIOs: reset (strongly recommended), and
+powerdown (optional).
+
+Required properties:
+
+- compatible: "ti,tas5711", "ti,tas5717", or "ti,tas5719"
+- reg: The I2C address of the device
+- #sound-dai-cells: must be equal to 0
+
+Optional properties:
+
+- reset-gpios: GPIO specifier for the TAS571x's active low reset line
+- pdn-gpios: GPIO specifier for the TAS571x's active low powerdown line
+- clocks: clock phandle for the MCLK input
+- clock-names: should be "mclk"
+- AVDD-supply: regulator phandle for the AVDD supply (all chips)
+- DVDD-supply: regulator phandle for the DVDD supply (all chips)
+- HPVDD-supply: regulator phandle for the HPVDD supply (5717/5719)
+- PVDD_AB-supply: regulator phandle for the PVDD_AB supply (5717/5719)
+- PVDD_CD-supply: regulator phandle for the PVDD_CD supply (5717/5719)
+- PVDD_A-supply: regulator phandle for the PVDD_A supply (5711)
+- PVDD_B-supply: regulator phandle for the PVDD_B supply (5711)
+- PVDD_C-supply: regulator phandle for the PVDD_C supply (5711)
+- PVDD_D-supply: regulator phandle for the PVDD_D supply (5711)
+
+Example:
+
+ tas5717: audio-codec@2a {
+ compatible = "ti,tas5717";
+ reg = <0x2a>;
+ #sound-dai-cells = <0>;
+
+ reset-gpios = < 1 GPIO_ACTIVE_LOW>;
+ pdn-gpios = < 2 GPIO_ACTIVE_LOW>;
+
+ clocks = <_core CLK_I2S>;
+ clock-names = "mclk";
+ };
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 3/4] ASoC: tas571x: New driver for TI TAS571x power amplifiers
Introduce a new codec driver for the Texas Instruments
TAS5711/TAS5717/TAS5719 power amplifier chips. These chips are typically
used to take an I2S digital audio input and drive 10-20W into a pair of
speakers.
Signed-off-by: Kevin Cernekee
---
sound/soc/codecs/Kconfig | 5 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/tas571x.c | 520 +
sound/soc/codecs/tas571x.h | 33 +++
4 files changed, 560 insertions(+)
create mode 100644 sound/soc/codecs/tas571x.c
create mode 100644 sound/soc/codecs/tas571x.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 061c46587628..befff910d71a 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -104,6 +104,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_STAC9766 if SND_SOC_AC97_BUS
select SND_SOC_TAS2552 if I2C
select SND_SOC_TAS5086 if I2C
+ select SND_SOC_TAS571X if I2C
select SND_SOC_TFA9879 if I2C
select SND_SOC_TLV320AIC23_I2C if I2C
select SND_SOC_TLV320AIC23_SPI if SPI_MASTER
@@ -611,6 +612,10 @@ config SND_SOC_TAS5086
tristate "Texas Instruments TAS5086 speaker amplifier"
depends on I2C
+config SND_SOC_TAS571X
+ tristate "Texas Instruments TAS5711/TAS5717/TAS5719 power amplifiers"
+ depends on I2C
+
config SND_SOC_TFA9879
tristate "NXP Semiconductors TFA9879 amplifier"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index abe2d7edf65c..3dcf5ac85e89 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -106,6 +106,7 @@ snd-soc-sta350-objs := sta350.o
snd-soc-sta529-objs := sta529.o
snd-soc-stac9766-objs := stac9766.o
snd-soc-tas5086-objs := tas5086.o
+snd-soc-tas571x-objs := tas571x.o
snd-soc-tfa9879-objs := tfa9879.o
snd-soc-tlv320aic23-objs := tlv320aic23.o
snd-soc-tlv320aic23-i2c-objs := tlv320aic23-i2c.o
@@ -288,6 +289,7 @@ obj-$(CONFIG_SND_SOC_STA529) += snd-soc-sta529.o
obj-$(CONFIG_SND_SOC_STAC9766) += snd-soc-stac9766.o
obj-$(CONFIG_SND_SOC_TAS2552) += snd-soc-tas2552.o
obj-$(CONFIG_SND_SOC_TAS5086) += snd-soc-tas5086.o
+obj-$(CONFIG_SND_SOC_TAS571X) += snd-soc-tas571x.o
obj-$(CONFIG_SND_SOC_TFA9879) += snd-soc-tfa9879.o
obj-$(CONFIG_SND_SOC_TLV320AIC23) += snd-soc-tlv320aic23.o
obj-$(CONFIG_SND_SOC_TLV320AIC23_I2C) += snd-soc-tlv320aic23-i2c.o
diff --git a/sound/soc/codecs/tas571x.c b/sound/soc/codecs/tas571x.c
new file mode 100644
index ..ffdf48397491
--- /dev/null
+++ b/sound/soc/codecs/tas571x.c
@@ -0,0 +1,520 @@
+/*
+ * TAS571x amplifier audio driver
+ *
+ * Copyright (C) 2015 Google, Inc.
+ * Copyright (c) 2013 Daniel Mack
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tas571x.h"
+
+#define TAS571X_MAX_SUPPLIES 6
+
+struct tas571x_chip {
+ const char *const *supply_names;
+ int num_supply_names;
+ const struct snd_kcontrol_new *controls;
+ int num_controls;
+ const struct regmap_config *regmap_config;
+ int vol_reg_size;
+};
+
+struct tas571x_private {
+ const struct tas571x_chip *chip;
+ struct regmap *regmap;
+ struct regulator_bulk_data supplies[TAS571X_MAX_SUPPLIES];
+ struct clk *mclk;
+ unsigned intformat;
+ struct gpio_desc*reset_gpio;
+ struct gpio_desc*pdn_gpio;
+ struct snd_soc_codec_driver codec_driver;
+};
+
+static int tas571x_register_size(struct tas571x_private *priv, unsigned int
reg)
+{
+ switch (reg) {
+ case TAS571X_MVOL_REG:
+ case TAS571X_CH1_VOL_REG:
+ case TAS571X_CH2_VOL_REG:
+ return priv->chip->vol_reg_size;
+ default:
+ return 1;
+ }
+}
+
+static int tas571x_reg_write(void *context, unsigned int reg,
+unsigned int value)
+{
+ struct i2c_client *client = context;
+ struct tas571x_private *priv = i2c_get_clientdata(client);
+ unsigned int i, size;
+ uint8_t buf[5];
+ int ret;
+
+ size = tas571x_register_size(priv, reg);
+ buf[0] = reg;
+
+ for (i = size; i >= 1; --i) {
+ buf[i] = value;
+ value >>= 8;
+ }
+
+ ret = i2c_master_send(client, buf, size + 1);
+ if (ret == size + 1)
+ return 0;
+ else if (ret < 0)
+ return ret;
+
[PATCH V3 1/4] regmap: Use regcache_mark_dirty() to indicate power loss or reset
Existing regmap users call regcache_mark_dirty() as part of the
suspend/resume sequence, to tell regcache that non-default values need to
be resynced post-resume. Add an internal "no_sync_defaults" regmap flag
to remember this state, so that regcache_sync() can differentiate between
these two cases:
1) HW was reset, so any cache values that match map->reg_defaults can be
safely skipped. On some chips there are a lot of registers in the
reg_defaults list, so this optimization speeds things up quite a bit.
2) HW was not reset (maybe it was just clock-gated), so if we cached
any writes, they should be sent to the hardware regardless of whether
they match the HW default. Currently this will write out all values in
the regcache, since we don't maintain per-register dirty bits.
Suggested-by: Mark Brown
Signed-off-by: Kevin Cernekee
---
drivers/base/regmap/internal.h | 3 +++
drivers/base/regmap/regcache.c | 61 --
2 files changed, 44 insertions(+), 20 deletions(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index a13587b5c2be..b2b2849fc6d3 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -131,7 +131,10 @@ struct regmap {
struct reg_default *reg_defaults;
const void *reg_defaults_raw;
void *cache;
+ /* if set, the cache contains newer data than the HW */
u32 cache_dirty;
+ /* if set, the HW registers are known to match map->reg_defaults */
+ bool no_sync_defaults;
struct reg_default *patch;
int patch_regs;
diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
index 7eb7b3b98794..63af3103d0c6 100644
--- a/drivers/base/regmap/regcache.c
+++ b/drivers/base/regmap/regcache.c
@@ -253,6 +253,9 @@ static int regcache_default_sync(struct regmap *map,
unsigned int min,
unsigned int max)
{
unsigned int reg;
+ bool no_sync_defaults = map->no_sync_defaults;
+
+ map->no_sync_defaults = false;
for (reg = min; reg <= max; reg += map->reg_stride) {
unsigned int val;
@@ -266,10 +269,12 @@ static int regcache_default_sync(struct regmap *map,
unsigned int min,
if (ret)
return ret;
- /* Is this the hardware default? If so skip. */
- ret = regcache_lookup_reg(map, reg);
- if (ret >= 0 && val == map->reg_defaults[ret].def)
- continue;
+ if (no_sync_defaults) {
+ /* Is this the hardware default? If so skip. */
+ ret = regcache_lookup_reg(map, reg);
+ if (ret >= 0 && val == map->reg_defaults[ret].def)
+ continue;
+ }
map->cache_bypass = 1;
ret = _regmap_write(map, reg, val);
@@ -461,18 +466,23 @@ void regcache_cache_only(struct regmap *map, bool enable)
EXPORT_SYMBOL_GPL(regcache_cache_only);
/**
- * regcache_mark_dirty: Mark the register cache as dirty
+ * regcache_mark_dirty: Indicate that HW registers were reset to default values
*
* @map: map to mark
*
- * Mark the register cache as dirty, for example due to the device
- * having been powered down for suspend. If the cache is not marked
- * as dirty then the cache sync will be suppressed.
+ * Inform regcache that the device has been powered down or reset, so that
+ * on resume, regcache_sync() knows to write out all non-default values
+ * stored in the cache.
+ *
+ * If this function is not called, regcache_sync() will assume that
+ * the hardware state still matches the cache state, modulo any writes that
+ * happened when cache_only was true.
*/
void regcache_mark_dirty(struct regmap *map)
{
map->lock(map->lock_arg);
map->cache_dirty = true;
+ map->no_sync_defaults = true;
map->unlock(map->lock_arg);
}
EXPORT_SYMBOL_GPL(regcache_mark_dirty);
@@ -604,6 +614,9 @@ static int regcache_sync_block_single(struct regmap *map,
void *block,
{
unsigned int i, regtmp, val;
int ret;
+ bool no_sync_defaults = map->no_sync_defaults;
+
+ map->no_sync_defaults = false;
for (i = start; i < end; i++) {
regtmp = block_base + (i * map->reg_stride);
@@ -614,10 +627,12 @@ static int regcache_sync_block_single(struct regmap *map,
void *block,
val = regcache_get_val(map, block, i);
- /* Is this the hardware default? If so skip. */
- ret = regcache_lookup_reg(map, regtmp);
- if (ret >= 0 && val == map->reg_defaults[ret].def)
- continue;
+ if (no_sync_defaults) {
+ /* Is this the hardware default? If so skip. */
+ ret = regcache_lookup_reg(map, regtmp);
+ if (ret >= 0 && val ==
[PATCH V3 0/4] tas571x amplifier driver
V2->V3: Revert earlier changes to the regcache APIs. Change regcache_sync() so that regcache_mark_dirty() is used to indicate that the HW was reset. This allows tas571x (which does NOT call regcache_mark_dirty()) to use regcache_sync() to write back any register changes that occurred while in cache_only (tas571x pdn) mode. One assumption here is that regcache_sync() will be called once on resume, before any other writes. If it fails, the no_sync_defaults flag will be cleared and the next sync attempt, if any, will try to write out all contents of the cache. Kevin Cernekee (4): regmap: Use regcache_mark_dirty() to indicate power loss or reset ASoC: tas571x: Add DT binding document ASoC: tas571x: New driver for TI TAS571x power amplifiers MAINTAINERS: Add entry for tas571x ASoC codec driver .../devicetree/bindings/sound/tas571x.txt | 41 ++ MAINTAINERS| 6 + drivers/base/regmap/internal.h | 3 + drivers/base/regmap/regcache.c | 61 ++- sound/soc/codecs/Kconfig | 5 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tas571x.c | 520 + sound/soc/codecs/tas571x.h | 33 ++ 8 files changed, 651 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/tas571x.txt create mode 100644 sound/soc/codecs/tas571x.c create mode 100644 sound/soc/codecs/tas571x.h -- 2.2.0.rc0.207.ga3a616c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] toshiba_acpi: Driver cleanup
These patches cleanup the driver from some no longer needed
functions, renames hci_{read, write}1 functions and also some comment
blocks were changed.
Azael Avalos (3):
toshiba_acpi: Remove no longer needed hci_{read, write}2 functions
toshiba_acpi: Rename hci_{read, write}1 functions
toshiba_acpi: Cleanup blank lines after comment blocks
drivers/platform/x86/toshiba_acpi.c | 114 +++-
1 file changed, 46 insertions(+), 68 deletions(-)
--
2.3.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] toshiba_bluetooth: Add rfkill code to driver
These patches add support to use the rfkill core functionality to the Toshiba bluetooth driver and adapting the existing code to it. Changes since v1: - Merged patches two and six to avoid a broken dependency - Merged patches three and four - The debug message is now printed in one line instead of three - Typos in comments Azael Avalos (4): toshiba_bluetooth: Add a container struct named toshiba_bluetooth_dev toshiba_bluetooth: Add RFKill handler functions toshiba_bluetooth: Adapt *_enable, *_notify and *_resume functions to rfkill toshiba_bluetooth: Change BT status message to debug drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/toshiba_bluetooth.c | 174 --- 2 files changed, 135 insertions(+), 40 deletions(-) -- 2.3.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] toshiba_acpi: Rename hci_{read, write}1 functions
This patch simply renames the hci_{read, write}1 functions to
hci_{read, write}.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 44 ++---
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index e593762..19efb05 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -326,13 +326,13 @@ static acpi_status tci_raw(struct toshiba_acpi_dev *dev,
}
/*
- * Common hci tasks (get or set one or two value)
+ * Common hci tasks
*
* In addition to the ACPI status, the HCI system returns a result which
* may be useful (such as "not supported").
*/
-static u32 hci_write1(struct toshiba_acpi_dev *dev, u32 reg, u32 in1)
+static u32 hci_write(struct toshiba_acpi_dev *dev, u32 reg, u32 in1)
{
u32 in[TCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
u32 out[TCI_WORDS];
@@ -341,7 +341,7 @@ static u32 hci_write1(struct toshiba_acpi_dev *dev, u32
reg, u32 in1)
return ACPI_SUCCESS(status) ? out[0] : TOS_FAILURE;
}
-static u32 hci_read1(struct toshiba_acpi_dev *dev, u32 reg, u32 *out1)
+static u32 hci_read(struct toshiba_acpi_dev *dev, u32 reg, u32 *out1)
{
u32 in[TCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 };
u32 out[TCI_WORDS];
@@ -596,7 +596,7 @@ static enum led_brightness toshiba_kbd_backlight_get(struct
led_classdev *cdev)
u32 state, result;
/* Check the keyboard backlight state */
- result = hci_read1(dev, HCI_KBD_ILLUMINATION, );
+ result = hci_read(dev, HCI_KBD_ILLUMINATION, );
if (result == TOS_FAILURE || result == TOS_INPUT_DATA_ERROR) {
pr_err("ACPI call to get the keyboard backlight failed\n");
return LED_OFF;
@@ -617,7 +617,7 @@ static void toshiba_kbd_backlight_set(struct led_classdev
*cdev,
/* Set the keyboard backlight state */
state = brightness ? 1 : 0;
- result = hci_write1(dev, HCI_KBD_ILLUMINATION, state);
+ result = hci_write(dev, HCI_KBD_ILLUMINATION, state);
if (result == TOS_FAILURE || result == TOS_INPUT_DATA_ERROR) {
pr_err("ACPI call to set KBD Illumination mode failed\n");
return;
@@ -1188,7 +1188,7 @@ static int get_tr_backlight_status(struct
toshiba_acpi_dev *dev, bool *enabled)
u32 hci_result;
u32 status;
- hci_result = hci_read1(dev, HCI_TR_BACKLIGHT, );
+ hci_result = hci_read(dev, HCI_TR_BACKLIGHT, );
*enabled = !status;
return hci_result == TOS_SUCCESS ? 0 : -EIO;
}
@@ -1198,7 +1198,7 @@ static int set_tr_backlight_status(struct
toshiba_acpi_dev *dev, bool enable)
u32 hci_result;
u32 value = !enable;
- hci_result = hci_write1(dev, HCI_TR_BACKLIGHT, value);
+ hci_result = hci_write(dev, HCI_TR_BACKLIGHT, value);
return hci_result == TOS_SUCCESS ? 0 : -EIO;
}
@@ -1221,7 +1221,7 @@ static int __get_lcd_brightness(struct toshiba_acpi_dev
*dev)
brightness++;
}
- hci_result = hci_read1(dev, HCI_LCD_BRIGHTNESS, );
+ hci_result = hci_read(dev, HCI_LCD_BRIGHTNESS, );
if (hci_result == TOS_SUCCESS)
return brightness + (value >> HCI_LCD_BRIGHTNESS_SHIFT);
@@ -1276,7 +1276,7 @@ static int set_lcd_brightness(struct toshiba_acpi_dev
*dev, int value)
}
value = value << HCI_LCD_BRIGHTNESS_SHIFT;
- hci_result = hci_write1(dev, HCI_LCD_BRIGHTNESS, value);
+ hci_result = hci_write(dev, HCI_LCD_BRIGHTNESS, value);
return hci_result == TOS_SUCCESS ? 0 : -EIO;
}
@@ -1326,7 +1326,7 @@ static int get_video_status(struct toshiba_acpi_dev *dev,
u32 *status)
{
u32 hci_result;
- hci_result = hci_read1(dev, HCI_VIDEO_OUT, status);
+ hci_result = hci_read(dev, HCI_VIDEO_OUT, status);
return hci_result == TOS_SUCCESS ? 0 : -EIO;
}
@@ -1432,7 +1432,7 @@ static int get_fan_status(struct toshiba_acpi_dev *dev,
u32 *status)
{
u32 hci_result;
- hci_result = hci_read1(dev, HCI_FAN, status);
+ hci_result = hci_read(dev, HCI_FAN, status);
return hci_result == TOS_SUCCESS ? 0 : -EIO;
}
@@ -1472,7 +1472,7 @@ static ssize_t fan_proc_write(struct file *file, const
char __user *buf,
if (sscanf(cmd, " force_on : %i", ) == 1 &&
value >= 0 && value <= 1) {
- hci_result = hci_write1(dev, HCI_FAN, value);
+ hci_result = hci_write(dev, HCI_FAN, value);
if (hci_result == TOS_SUCCESS)
dev->force_fan = value;
else
@@ -1500,7 +1500,7 @@ static int keys_proc_show(struct seq_file *m, void *v)
u32 value;
if (!dev->key_event_valid && dev->system_event_supported) {
- hci_result = hci_read1(dev, HCI_SYSTEM_EVENT, );
+ hci_result = hci_read(dev, HCI_SYSTEM_EVENT, );
[PATCH 3/3] toshiba_acpi: Cleanup blank lines after comment blocks
This patch removes some blank lines after comment blocks, capitalizes
some comments first words and adds a few comments to the beggining
of some functions.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 19efb05..dca3dd2 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -78,10 +78,9 @@ MODULE_LICENSE("GPL");
* SCI stands for "System Configuration Interface" which aim is to
* conceal differences in hardware between different models.
*/
-
#define TCI_WORDS 6
-/* operations */
+/* Operations */
#define HCI_SET0xff00
#define HCI_GET0xfe00
#define SCI_OPEN 0xf100
@@ -89,7 +88,7 @@ MODULE_LICENSE("GPL");
#define SCI_GET0xf300
#define SCI_SET0xf400
-/* return codes */
+/* Return codes */
#define TOS_SUCCESS0x
#define TOS_OPEN_CLOSE_OK 0x0044
#define TOS_FAILURE0x1000
@@ -104,7 +103,7 @@ MODULE_LICENSE("GPL");
#define TOS_NOT_INITIALIZED0x8d50
#define TOS_NOT_INSTALLED 0x8e00
-/* registers */
+/* Registers */
#define HCI_FAN0x0004
#define HCI_TR_BACKLIGHT 0x0005
#define HCI_SYSTEM_EVENT 0x0016
@@ -126,7 +125,7 @@ MODULE_LICENSE("GPL");
#define SCI_TOUCHPAD 0x050e
#define SCI_KBD_FUNCTION_KEYS 0x0522
-/* field definitions */
+/* Field definitions */
#define HCI_ACCEL_MASK 0x7fff
#define HCI_HOTKEY_DISABLE 0x0b
#define HCI_HOTKEY_ENABLE 0x09
@@ -272,7 +271,6 @@ static const struct dmi_system_id
toshiba_vendor_backlight_dmi[] = {
/*
* Utility
*/
-
static inline void _set_bit(u32 *word, u32 mask, int value)
{
*word = (*word & ~mask) | (mask * value);
@@ -281,7 +279,6 @@ static inline void _set_bit(u32 *word, u32 mask, int value)
/*
* ACPI interface wrappers
*/
-
static int write_acpi_int(const char *methodName, int val)
{
acpi_status status;
@@ -331,7 +328,6 @@ static acpi_status tci_raw(struct toshiba_acpi_dev *dev,
* In addition to the ACPI status, the HCI system returns a result which
* may be useful (such as "not supported").
*/
-
static u32 hci_write(struct toshiba_acpi_dev *dev, u32 reg, u32 in1)
{
u32 in[TCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
@@ -358,7 +354,6 @@ static u32 hci_read(struct toshiba_acpi_dev *dev, u32 reg,
u32 *out1)
/*
* Common sci tasks
*/
-
static int sci_open(struct toshiba_acpi_dev *dev)
{
u32 in[TCI_WORDS] = { SCI_OPEN, 0, 0, 0, 0, 0 };
@@ -1183,6 +1178,7 @@ static int toshiba_hotkey_event_type_get(struct
toshiba_acpi_dev *dev,
return 0;
}
+/* Transflective Backlight */
static int get_tr_backlight_status(struct toshiba_acpi_dev *dev, bool *enabled)
{
u32 hci_result;
@@ -1204,6 +1200,7 @@ static int set_tr_backlight_status(struct
toshiba_acpi_dev *dev, bool enable)
static struct proc_dir_entry *toshiba_proc_dir /*= 0*/;
+/* LCD Brightness */
static int __get_lcd_brightness(struct toshiba_acpi_dev *dev)
{
u32 hci_result;
@@ -1322,6 +1319,7 @@ static const struct file_operations lcd_proc_fops = {
.write = lcd_proc_write,
};
+/* Video-Out */
static int get_video_status(struct toshiba_acpi_dev *dev, u32 *status)
{
u32 hci_result;
@@ -1411,7 +1409,8 @@ static ssize_t video_proc_write(struct file *file, const
char __user *buf,
_set_bit(_video_out, HCI_VIDEO_OUT_TV, tv_out);
/*
* To avoid unnecessary video disruption, only write the new
-* video setting if something changed. */
+* video setting if something changed.
+*/
if (new_video_out != video_out)
ret = write_acpi_int(METHOD_VIDEO_OUT, new_video_out);
}
@@ -1428,6 +1427,7 @@ static const struct file_operations video_proc_fops = {
.write = video_proc_write,
};
+/* Fan status */
static int get_fan_status(struct toshiba_acpi_dev *dev, u32 *status)
{
u32 hci_result;
@@ -1583,7 +1583,6 @@ static const struct file_operations version_proc_fops = {
/*
* Proc and module init
*/
-
#define PROC_TOSHIBA "toshiba"
static void create_toshiba_proc_entries(struct toshiba_acpi_dev *dev)
@@ -2324,9 +2323,7 @@ static void toshiba_acpi_hotkey_work(struct work_struct
*work)
pr_err("ACPI NTFY method execution failed\n");
}
-/*
- * Returns hotkey scancode, or < 0 on failure.
- */
+/* Returns hotkey scancode, or < 0 on failure */
static int
[PATCH 1/3] toshiba_acpi: Remove no longer needed hci_{read, write}2 functions
This patch removes the hci_{read, write}2 functions from the driver,
and the toshiba_hotkey_event_type_get function was adapted to use the
tci_raw function.
The hci_write2 function was only used by the bluetooth rfkill code,
but since its removal, it was causing build warnings, and the
hci_read2 function was only used by the toshiba_hotkey_event_type_get
function.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 39 +++--
1 file changed, 7 insertions(+), 32 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 8ee7c24..e593762 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -355,31 +355,6 @@ static u32 hci_read1(struct toshiba_acpi_dev *dev, u32
reg, u32 *out1)
return out[0];
}
-static u32 hci_write2(struct toshiba_acpi_dev *dev, u32 reg, u32 in1, u32 in2)
-{
- u32 in[TCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
- u32 out[TCI_WORDS];
- acpi_status status = tci_raw(dev, in, out);
-
- return ACPI_SUCCESS(status) ? out[0] : TOS_FAILURE;
-}
-
-static u32 hci_read2(struct toshiba_acpi_dev *dev,
-u32 reg, u32 *out1, u32 *out2)
-{
- u32 in[TCI_WORDS] = { HCI_GET, reg, *out1, *out2, 0, 0 };
- u32 out[TCI_WORDS];
- acpi_status status = tci_raw(dev, in, out);
-
- if (ACPI_FAILURE(status))
- return TOS_FAILURE;
-
- *out1 = out[2];
- *out2 = out[3];
-
- return out[0];
-}
-
/*
* Common sci tasks
*/
@@ -1190,20 +1165,20 @@ static int toshiba_usb_three_set(struct
toshiba_acpi_dev *dev, u32 state)
static int toshiba_hotkey_event_type_get(struct toshiba_acpi_dev *dev,
u32 *type)
{
- u32 val1 = 0x03;
- u32 val2 = 0;
- u32 result;
+ u32 in[TCI_WORDS] = { HCI_GET, HCI_SYSTEM_INFO, 0x03, 0, 0, 0 };
+ u32 out[TCI_WORDS];
+ acpi_status status;
- result = hci_read2(dev, HCI_SYSTEM_INFO, , );
- if (result == TOS_FAILURE) {
+ status = tci_raw(dev, in, out);
+ if (ACPI_FAILURE(status)) {
pr_err("ACPI call to get System type failed\n");
return -EIO;
- } else if (result == TOS_NOT_SUPPORTED) {
+ } else if (out[0] == TOS_NOT_SUPPORTED) {
pr_info("System type not supported\n");
return -ENODEV;
}
- *type = val2;
+ *type = out[3];
return 0;
}
--
2.3.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] toshiba_bluetooth: Change BT status message to debug
The function toshiba_bluetooth_status is currently printing the
status of the device whenever it is queried, but since the
introduction of the rfkill poll code, this value will get printed
everytime the poll occurs.
This patch removes the status message from the *_status function, and
adds a debug message to the *_sync_status function printing the
bluetooth device raw status, killswitch, plug and power states of the
device as well.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_bluetooth.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/toshiba_bluetooth.c
b/drivers/platform/x86/toshiba_bluetooth.c
index 9867ccd..f84cd6f 100644
--- a/drivers/platform/x86/toshiba_bluetooth.c
+++ b/drivers/platform/x86/toshiba_bluetooth.c
@@ -99,8 +99,6 @@ static int toshiba_bluetooth_status(acpi_handle handle)
return -ENXIO;
}
- pr_info("Bluetooth status %llu\n", status);
-
return status;
}
@@ -156,6 +154,9 @@ static int toshiba_bluetooth_sync_status(struct
toshiba_bluetooth_dev *bt_dev)
bt_dev->killswitch = (status & BT_KILLSWITCH_MASK) ? true : false;
bt_dev->plugged = (status & BT_PLUGGED_MASK) ? true : false;
bt_dev->powered = (status & BT_POWER_MASK) ? true : false;
+
+ pr_debug("Bluetooth status %llu killswitch %d plugged %d powered %d\n",
+status, bt_dev->killswitch, bt_dev->plugged, bt_dev->powered);
return 0;
}
--
2.3.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] toshiba_bluetooth: Add a container struct named toshiba_bluetooth_dev
This patch adds a struct named toshiba_bluetooth_dev, which will be
used to contain the acpi_device struct and bluetooth status booleans.
This struct will also be used by later patches to store the rfkill
struct as well.
Also, a helper function named toshiba_bluetooth_sync_status was added
to be also used by upcomming patches.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_bluetooth.c | 47 +++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/toshiba_bluetooth.c
b/drivers/platform/x86/toshiba_bluetooth.c
index 2498007..a619ba6 100644
--- a/drivers/platform/x86/toshiba_bluetooth.c
+++ b/drivers/platform/x86/toshiba_bluetooth.c
@@ -34,6 +34,14 @@ MODULE_AUTHOR("Jes Sorensen ");
MODULE_DESCRIPTION("Toshiba Laptop ACPI Bluetooth Enable Driver");
MODULE_LICENSE("GPL");
+struct toshiba_bluetooth_dev {
+ struct acpi_device *acpi_dev;
+
+ bool killswitch;
+ bool plugged;
+ bool powered;
+};
+
static int toshiba_bt_rfkill_add(struct acpi_device *device);
static int toshiba_bt_rfkill_remove(struct acpi_device *device);
static void toshiba_bt_rfkill_notify(struct acpi_device *device, u32 event);
@@ -165,6 +173,25 @@ static int toshiba_bluetooth_disable(acpi_handle handle)
return 0;
}
+/* Helper function */
+static int toshiba_bluetooth_sync_status(struct toshiba_bluetooth_dev *bt_dev)
+{
+ int status;
+
+ status = toshiba_bluetooth_status(bt_dev->acpi_dev->handle);
+ if (status < 0) {
+ pr_err("Could not sync bluetooth device status\n");
+ return status;
+ }
+
+ bt_dev->killswitch = (status & BT_KILLSWITCH_MASK) ? true : false;
+ bt_dev->plugged = (status & BT_PLUGGED_MASK) ? true : false;
+ bt_dev->powered = (status & BT_POWER_MASK) ? true : false;
+
+ return 0;
+}
+
+/* ACPI driver functions */
static void toshiba_bt_rfkill_notify(struct acpi_device *device, u32 event)
{
toshiba_bluetooth_enable(device->handle);
@@ -179,6 +206,7 @@ static int toshiba_bt_resume(struct device *dev)
static int toshiba_bt_rfkill_add(struct acpi_device *device)
{
+ struct toshiba_bluetooth_dev *bt_dev;
int result;
result = toshiba_bluetooth_present(device->handle);
@@ -187,17 +215,34 @@ static int toshiba_bt_rfkill_add(struct acpi_device
*device)
pr_info("Toshiba ACPI Bluetooth device driver\n");
+ bt_dev = kzalloc(sizeof(*bt_dev), GFP_KERNEL);
+ if (!bt_dev)
+ return -ENOMEM;
+ bt_dev->acpi_dev = device;
+ device->driver_data = bt_dev;
+ dev_set_drvdata(>dev, bt_dev);
+
+ result = toshiba_bluetooth_sync_status(bt_dev);
+ if (result) {
+ kfree(bt_dev);
+ return result;
+ }
+
/* Enable the BT device */
result = toshiba_bluetooth_enable(device->handle);
if (result)
- return result;
+ kfree(bt_dev);
return result;
}
static int toshiba_bt_rfkill_remove(struct acpi_device *device)
{
+ struct toshiba_bluetooth_dev *bt_dev = acpi_driver_data(device);
+
/* clean up */
+ kfree(bt_dev);
+
return toshiba_bluetooth_disable(device->handle);
}
--
2.3.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/4] toshiba_bluetooth: Adapt *_enable, *_notify and *_resume functions to rfkill
This patch adapts toshiba_bluetooth_enable, toshiba_bt_rfkill_notify
and toshiba_bt_resume functions to rfkill.
The *_enable function was cleaned from code that the rfkill code now
provides, and the other two functions were modified to update the rfkill
switch status, as they were only calling toshiba_bluetooth_enable.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_bluetooth.c | 47
1 file changed, 18 insertions(+), 29 deletions(-)
diff --git a/drivers/platform/x86/toshiba_bluetooth.c
b/drivers/platform/x86/toshiba_bluetooth.c
index a3b2d38..9867ccd 100644
--- a/drivers/platform/x86/toshiba_bluetooth.c
+++ b/drivers/platform/x86/toshiba_bluetooth.c
@@ -107,33 +107,6 @@ static int toshiba_bluetooth_status(acpi_handle handle)
static int toshiba_bluetooth_enable(acpi_handle handle)
{
acpi_status result;
- bool killswitch;
- bool powered;
- bool plugged;
- int status;
-
- /*
-* Query ACPI to verify RFKill switch is set to 'on'.
-* If not, we return silently, no need to report it as
-* an error.
-*/
- status = toshiba_bluetooth_status(handle);
- if (status < 0)
- return status;
-
- killswitch = (status & BT_KILLSWITCH_MASK) ? true : false;
- powered = (status & BT_POWER_MASK) ? true : false;
- plugged = (status & BT_PLUGGED_MASK) ? true : false;
-
- if (!killswitch)
- return 0;
- /*
-* This check ensures to only enable the device if it is powered
-* off or detached, as some recent devices somehow pass the killswitch
-* test, causing a loop enabling/disabling the device, see bug 93911.
-*/
- if (powered || plugged)
- return 0;
result = acpi_evaluate_object(handle, "AUSB", NULL, NULL);
if (ACPI_FAILURE(result)) {
@@ -233,13 +206,29 @@ static const struct rfkill_ops rfk_ops = {
/* ACPI driver functions */
static void toshiba_bt_rfkill_notify(struct acpi_device *device, u32 event)
{
- toshiba_bluetooth_enable(device->handle);
+ struct toshiba_bluetooth_dev *bt_dev = acpi_driver_data(device);
+
+ if (toshiba_bluetooth_sync_status(bt_dev))
+ return;
+
+ rfkill_set_hw_state(bt_dev->rfk, !bt_dev->killswitch);
}
#ifdef CONFIG_PM_SLEEP
static int toshiba_bt_resume(struct device *dev)
{
- return toshiba_bluetooth_enable(to_acpi_device(dev)->handle);
+ struct toshiba_bluetooth_dev *bt_dev;
+ int ret;
+
+ bt_dev = acpi_driver_data(to_acpi_device(dev));
+
+ ret = toshiba_bluetooth_sync_status(bt_dev);
+ if (ret)
+ return ret;
+
+ rfkill_set_hw_state(bt_dev->rfk, !bt_dev->killswitch);
+
+ return 0;
}
#endif
--
2.3.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] toshiba_bluetooth: Add RFKill handler functions
This patch adds RFKill handler functions to the driver, allowing it
to register and update the rfkill switch status.
Also, a comment block was moved from the header to the poll function,
as it explains why we need to poll the killswitch on older devices.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/toshiba_bluetooth.c | 77
2 files changed, 69 insertions(+), 9 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 822171c..399085d 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -642,6 +642,7 @@ config ACPI_TOSHIBA
config TOSHIBA_BT_RFKILL
tristate "Toshiba Bluetooth RFKill switch support"
depends on ACPI
+ depends on RFKILL || RFKILL = n
---help---
This driver adds support for Bluetooth events for the RFKill
switch on modern Toshiba laptops with full ACPI support and
diff --git a/drivers/platform/x86/toshiba_bluetooth.c
b/drivers/platform/x86/toshiba_bluetooth.c
index a619ba6..a3b2d38 100644
--- a/drivers/platform/x86/toshiba_bluetooth.c
+++ b/drivers/platform/x86/toshiba_bluetooth.c
@@ -10,12 +10,6 @@
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
- *
- * Note the Toshiba Bluetooth RFKill switch seems to be a strange
- * fish. It only provides a BT event when the switch is flipped to
- * the 'on' position. When flipping it to 'off', the USB device is
- * simply pulled away underneath us, without any BT event being
- * delivered.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -25,6 +19,7 @@
#include
#include
#include
+#include
#define BT_KILLSWITCH_MASK 0x01
#define BT_PLUGGED_MASK0x40
@@ -36,6 +31,7 @@ MODULE_LICENSE("GPL");
struct toshiba_bluetooth_dev {
struct acpi_device *acpi_dev;
+ struct rfkill *rfk;
bool killswitch;
bool plugged;
@@ -191,6 +187,49 @@ static int toshiba_bluetooth_sync_status(struct
toshiba_bluetooth_dev *bt_dev)
return 0;
}
+/* RFKill handlers */
+static int bt_rfkill_set_block(void *data, bool blocked)
+{
+ struct toshiba_bluetooth_dev *bt_dev = data;
+ int ret;
+
+ ret = toshiba_bluetooth_sync_status(bt_dev);
+ if (ret)
+ return ret;
+
+ if (!bt_dev->killswitch)
+ return 0;
+
+ if (blocked)
+ ret = toshiba_bluetooth_disable(bt_dev->acpi_dev->handle);
+ else
+ ret = toshiba_bluetooth_enable(bt_dev->acpi_dev->handle);
+
+ return ret;
+}
+
+static void bt_rfkill_poll(struct rfkill *rfkill, void *data)
+{
+ struct toshiba_bluetooth_dev *bt_dev = data;
+
+ if (toshiba_bluetooth_sync_status(bt_dev))
+ return;
+
+ /*
+* Note the Toshiba Bluetooth RFKill switch seems to be a strange
+* fish. It only provides a BT event when the switch is flipped to
+* the 'on' position. When flipping it to 'off', the USB device is
+* simply pulled away underneath us, without any BT event being
+* delivered.
+*/
+ rfkill_set_hw_state(bt_dev->rfk, !bt_dev->killswitch);
+}
+
+static const struct rfkill_ops rfk_ops = {
+ .set_block = bt_rfkill_set_block,
+ .poll = bt_rfkill_poll,
+};
+
/* ACPI driver functions */
static void toshiba_bt_rfkill_notify(struct acpi_device *device, u32 event)
{
@@ -228,10 +267,25 @@ static int toshiba_bt_rfkill_add(struct acpi_device
*device)
return result;
}
- /* Enable the BT device */
- result = toshiba_bluetooth_enable(device->handle);
- if (result)
+ bt_dev->rfk = rfkill_alloc("Toshiba Bluetooth",
+ >dev,
+ RFKILL_TYPE_BLUETOOTH,
+ _ops,
+ bt_dev);
+ if (!bt_dev->rfk) {
+ pr_err("Unable to allocate rfkill device\n");
+ kfree(bt_dev);
+ return -ENOMEM;
+ }
+
+ rfkill_set_hw_state(bt_dev->rfk, !bt_dev->killswitch);
+
+ result = rfkill_register(bt_dev->rfk);
+ if (result) {
+ pr_err("Unable to register rfkill device\n");
+ rfkill_destroy(bt_dev->rfk);
kfree(bt_dev);
+ }
return result;
}
@@ -241,6 +295,11 @@ static int toshiba_bt_rfkill_remove(struct acpi_device
*device)
struct toshiba_bluetooth_dev *bt_dev = acpi_driver_data(device);
/* clean up */
+ if (bt_dev->rfk) {
+ rfkill_unregister(bt_dev->rfk);
+ rfkill_destroy(bt_dev->rfk);
+ }
+
kfree(bt_dev);
return toshiba_bluetooth_disable(device->handle);
--
2.3.6
--
To unsubscribe from this list: send the
