Purchase Inquiry!
Hi there, How are you today? I would like to purchase items from your company.Do you ship to Australia and accept USA credit cards as a form of payment? Your prompt response is esteemed. Thanks Best Regards , Albert Fryra ELDERS LIMITED
Re: [PATCH] Optimize int_sqrt for small values for faster idle
Hello,
> - m = 1UL << (BITS_PER_LONG - 2);
> + if (x <= 0x) {
> + if (m <= 0xff)
> + m = 1UL << (8 - 2);
> + else
> + m = 1UL << (16 - 2);
> + } else if (x <= 0x)
> + m = 1UL << (32 - 2);
> + else
> + m = 1UL << (BITS_PER_LONG - 2);
>while (m != 0) {
>b = y + m;
>y >>= 1;
>
I think, m can be initialized with
1 << (greatest multiple of 2 less than or equal to (position of most
significant bit of x))
i.e. 1 << ((position of most significant bit of x) & 62)
without changing the outcome of the original algorithm (as long as x>= 2).
I believe, that for (position of most significant bit of x) there is an
efficient macro, and
some processors directly have an instruction for it. So this would probably be
faster than your suggestion
for an initial starting value and give an even better starting value (cutting
in some cases further on the number of
while loop interations).
If one just wants to achieve a result with a certain relative error in terms of
the fraction of the input, one can
probably only look at the most significant bit and a few following bits of x.
Sincerely,
Thomas
[PATCH] ASoC: fsl-asoc-card: Don't add DAPM routes for ASRC if it doesn't exist
From: Nicolin Chen
There are a pair of warnings when ASRC is absent in the DTB:
fsl-asoc-card sound: ASoC: no source widget found for ASRC-Playback
fsl-asoc-card sound: ASoC: Failed to add route ASRC-Playback -> direct ->
CPU-Playback
fsl-asoc-card sound: ASoC: no sink widget found for ASRC-Capture
fsl-asoc-card sound: ASoC: Failed to add route CPU-Capture -> direct ->
ASRC-Capture
This is because the driver is still trying to add DAPM routes for ASRC
even if it doesn't exist on that platform.
The warnings are harmless but it might be annoying. So this patch drops
the DAPM routes of ASRC when it's absent in the DAI link.
Signed-off-by: Nicolin Chen
---
sound/soc/fsl/fsl-asoc-card.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 562b3bd..3d40797 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -99,19 +99,26 @@ struct fsl_asoc_card_priv {
/**
* This dapm route map exsits for DPCM link only.
* The other routes shall go through Device Tree.
+ *
+ * Note: keep all ASRC routes in the second half
+ * to drop them easily for non-ASRC cases.
*/
static const struct snd_soc_dapm_route audio_map[] = {
- {"CPU-Playback", NULL, "ASRC-Playback"},
+ /* 1st half -- Normal DAPM routes */
{"Playback", NULL, "CPU-Playback"},
- {"ASRC-Capture", NULL, "CPU-Capture"},
{"CPU-Capture", NULL, "Capture"},
+ /* 2nd half -- ASRC DAPM routes */
+ {"CPU-Playback", NULL, "ASRC-Playback"},
+ {"ASRC-Capture", NULL, "CPU-Capture"},
};
static const struct snd_soc_dapm_route audio_map_ac97[] = {
- {"AC97 Playback", NULL, "ASRC-Playback"},
+ /* 1st half -- Normal DAPM routes */
{"Playback", NULL, "AC97 Playback"},
- {"ASRC-Capture", NULL, "AC97 Capture"},
{"AC97 Capture", NULL, "Capture"},
+ /* 2nd half -- ASRC DAPM routes */
+ {"AC97 Playback", NULL, "ASRC-Playback"},
+ {"ASRC-Capture", NULL, "AC97 Capture"},
};
/* Add all possible widgets into here without being redundant */
@@ -593,6 +600,10 @@ static int fsl_asoc_card_probe(struct platform_device
*pdev)
priv->card.dapm_widgets = fsl_asoc_card_dapm_widgets;
priv->card.num_dapm_widgets = ARRAY_SIZE(fsl_asoc_card_dapm_widgets);
+ /* Drop the second half of DAPM routes -- ASRC */
+ if (!asrc_pdev)
+ priv->card.num_dapm_routes /= 2;
+
memcpy(priv->dai_link, fsl_asoc_card_dai,
sizeof(struct snd_soc_dai_link) * ARRAY_SIZE(priv->dai_link));
--
1.9.1
Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences
> On Jan 30, 2016, at 7:32 PM, Matthew Wilcox wrote:
>
>> On Fri, Jan 29, 2016 at 10:01:13PM -0800, Dan Williams wrote:
>>> On Fri, Jan 29, 2016 at 9:28 PM, Matthew Wilcox
>>> wrote:
>>> If we store the PFN of the underlying page instead, we don't have this
>>> problem. Instead, we have a different problem; of the device going
>>> away under us. I'm trying to find the code which tears down PTEs when
>>> the device goes away, and I'm not seeing it. What do we do about user
>>> mappings of the device?
>>
>> I deferred the dax tear down code until next cycle as Al rightly
>> pointed out some needed re-works:
>>
>> https://lists.01.org/pipermail/linux-nvdimm/2016-January/003995.html
>
> Thanks; I eventually found it in my email somewhere over the Pacific.
>
> I did probably 70% of the work needed to switch the radix tree over to
> storing PFNs instead of sectors. It seems viable, though it's a big
> change from where we are today:
At one point I had kaddrs in the radix tree, so I could just pull the addresses
out
and flush them. That would save us a pfn -> kaddrs conversion before flush.
Is there a reason to store pnfs instead of kaddrs in the radix tree?
>
> fs/dax.c | 415 +++--
> include/linux/dax.h| 3 +-
> include/linux/pfn_t.h | 33 +++-
> include/linux/radix-tree.h | 9 -
> 4 files changed, 236 insertions(+), 224 deletions(-)
>
> I'll try and get that finished off this week.
>
> One concrete and easily-separable piece is that dax_clear_blocks() has
> the wrong signature. It currently takes an inode & block as parameters;
> it has no way of finding out the correct block device. It's only two
> callers are filesystems (ext2 and xfs). Those filesystems should be
> passing the block_device instead of the inode. But without the inode,
> we can't convert a block number to a sector number, so we also need
> to pass the sector number, not the block number. It still has type
> sector_t, annoyingly.
>
> @@ -63,12 +238,11 @@ static void dax_unmap_atomic(struct block_device *bdev,
> * and hence this means the stack from this point must follow GFP_NOFS
> * semantics for all operations.
> */
> -int dax_clear_blocks(struct inode *inode, sector_t block, long _size)
> +int dax_clear_blocks(struct block_device *bdev, sector_t sector, long size)
> {
> - struct block_device *bdev = inode->i_sb->s_bdev;
>struct blk_dax_ctl dax = {
> - .sector = block << (inode->i_blkbits - 9),
> - .size = _size,
> + .sector = sector,
> + .size = size,
>};
>
>might_sleep();
>
> but I haven't looked at doing the conversion of xfs or ext2 to use that
> new interface.
> ___
> Linux-nvdimm mailing list
> linux-nvd...@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH 08/14] ARM: dts: sun8i-a83t: add mmc clock nodes
On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
wrote:
> mmc clocks are compatible with that of earlier sun8i socs.
> This adds mmc0, mmc1, and mmc2 clock nodes for A83T.
>
> Signed-off-by: Vishnu Patekar
Acked-by: Chen-Yu Tsai
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 568d6fb..b8c8b60 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -238,6 +238,36 @@
> "bus_uart2", "bus_uart3",
> "bus_uart4";
> };
> +
> + mmc0_clk: clk@01c20088 {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun4i-a10-mmc-clk";
> + reg = <0x01c20088 0x4>;
> + clocks = <>, <>;
> + clock-output-names = "mmc0",
> +"mmc0_output",
> +"mmc0_sample";
> + };
> +
> + mmc1_clk: clk@01c2008c {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun4i-a10-mmc-clk";
> + reg = <0x01c2008c 0x4>;
> + clocks = <>, <>;
> + clock-output-names = "mmc1",
> +"mmc1_output",
> +"mmc1_sample";
> + };
> +
> + mmc2_clk: clk@01c20090 {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun4i-a10-mmc-clk";
> + reg = <0x01c20090 0x4>;
> + clocks = <>, <>;
> + clock-output-names = "mmc2",
> +"mmc2_output",
> +"mmc2_sample";
> + };
> };
>
> soc {
> --
> 1.9.1
>
Re: [PATCH 07/14] ARM: dts: sun8i-a83t: Add basic clocks and resets
On Sun, Jan 31, 2016 at 9:20 AM, Vishnu Patekar
wrote:
> This adds A83T system bus clocks, bus gates, and clock resets.
>
> For ahb1 and ahb2, it's not clear which reset belongs to ahb1
> or ahb2; so named as ahb_reset0, ahb_reset1, ahb_reset2.
>
> Signed-off-by: Vishnu Patekar
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 127
> +-
> 1 file changed, 125 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 45b725c..568d6fb 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -146,6 +146,98 @@
> clocks = <>;
> clock-output-names = "osc16Md512";
> };
> +
> +
extra newline.
> + pll6: clk@01c20028 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun9i-a80-pll4-clk";
> + reg = <0x01c20028 0x4>;
> + clocks = <>;
> + clock-output-names = "pll6";
> + };
> +
> + pll6d2: pll6d2_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-factor-clock";
> + clock-div = <2>;
> + clock-mult = <1>;
> + clocks = <>;
> + clock-output-names = "pll6d2";
> + };
> +
> + ahb1: ahb1_clk@01c20054 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun8i-a83t-ahb1-clk";
> + reg = <0x01c20054 0x4>;
> + clocks = <>, <>, <>, <>;
> + clock-output-names = "ahb1";
> + };
> +
> + ahb2: ahb2_clk@01c2005c {
Just "clk" will do. We use "ahb1_clk" and "apb1_clk" because they have
the same address.
> + #clock-cells = <0>;
> + compatible = "allwinner,sun8i-h3-ahb2-clk";
> + reg = <0x01c2005c 0x4>;
> + clocks = <>, <>;
> + clock-output-names = "ahb2";
> + };
> +
> + apb1: apb1_clk@01c20054 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun8i-a83t-apb1-clk";
> + reg = <0x01c20054 0x4>;
> + clocks = <>;
> + clock-output-names = "apb1";
> + };
Keep these ordered by register address, not clock name.
> +
> + apb2: clk@01c20058 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-apb1-clk";
> + reg = <0x01c20058 0x4>;
> + clocks = <>, <>, <>, <>;
> + clock-output-names = "apb2";
> + };
> +
> + bus_gates: clk@01c20060 {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun8i-a83t-bus-gates-clk";
> + reg = <0x01c20060 0x10>;
> + clocks = <>, <>, <>, <>;
> + clock-names = "ahb1", "ahb2", "apb1", "apb2";
> + clock-indices = <1>, <5>, <6>,
> + <8>, <9>, <10>,
> + <13>, <14>, <17>,
> + <19>, <20>,
> + <21>, <24>,
> + <26>, <27>,
> + <29>, <32>,
> + <36>, <37>,
> + <40>, <43>,
> + <44>, <52>, <53>,
> + <54>, <65>,
> + <69>, <76>, <77>,
> + <78>, <79>, <96>,
> + <97>, <98>,
> + <112>, <113>,
> + <114>, <115>,
> + <116>;
> + clock-output-names = "bus_mipidsi", "bus_ss",
> "bus_dma",
> +"bus_mmc0", "bus_mmc1",
> "bus_mmc2",
> +"bus_nand", "bus_sdram",
> "bus_emac",
> +"bus_hstimer", "bus_spi0",
> +"bus_spi1", "bus_usb_drd",
"bus_usb_otg" would better match what we use for other SoCs.
> +"bus_ehci0", "bus_ehci1",
> +"bus_ohci0", "bus_ve",
> +"bus_lcd0", "bus_lcd1",
> +
[PATCH] arch/ia64/lib: Fix broken URL in comments
The URL to the book IA-64 and Elementary Functions in idiv32.S and idiv64.S just led to a 404 page, so I updated them with a known good link that others can reference. Signed-off-by: Sina Hamedian --- arch/ia64/lib/idiv32.S | 2 +- arch/ia64/lib/idiv64.S | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/ia64/lib/idiv32.S b/arch/ia64/lib/idiv32.S index 2ac28bf..c91b5b0 100644 --- a/arch/ia64/lib/idiv32.S +++ b/arch/ia64/lib/idiv32.S @@ -11,7 +11,7 @@ * * For more details on the theory behind these algorithms, see "IA-64 * and Elementary Functions" by Peter Markstein; HP Professional Books - * (http://www.hp.com/go/retailbooks/) + * (http://www.goodreads.com/book/show/2019887.Ia_64_and_Elementary_Functions) */ #include diff --git a/arch/ia64/lib/idiv64.S b/arch/ia64/lib/idiv64.S index f69bd2b..627573c 100644 --- a/arch/ia64/lib/idiv64.S +++ b/arch/ia64/lib/idiv64.S @@ -11,7 +11,7 @@ * * For more details on the theory behind these algorithms, see "IA-64 * and Elementary Functions" by Peter Markstein; HP Professional Books - * (http://www.hp.com/go/retailbooks/) + * (http://www.goodreads.com/book/show/2019887.Ia_64_and_Elementary_Functions) */ #include -- 2.5.0
Re: [PATCH 2/2] sched,time: call __acct_update_integrals once a jiffy
On Sun, 2016-01-31 at 03:52 +0100, Mike Galbraith wrote:
> On Sat, 2016-01-30 at 21:36 +0100, Frederic Weisbecker wrote:
> > On Sat, Jan 30, 2016 at 06:53:05PM +0100, Mike Galbraith wrote:
> > > On Sat, 2016-01-30 at 15:20 +0100, Frederic Weisbecker wrote:
> > > > On Fri, Jan 29, 2016 at 05:43:28PM -0500, Rik van Riel wrote:
> > >
> > > > > Run times for the microbenchmark:
> > > > >
> > > > > 4.4 3.8 seconds
> > > > > 4.5-rc1 3.7 seconds
> > > > > 4.5-rc1 + first patch 3.3 seconds
> > > > > 4.5-rc1 + both patches 2.3 seconds
> > > >
> > > > Very nice improvement!
> > >
> > > Tasty indeed.
> > >
> > > When nohz_full CPUs are not isolated, ie are being used as
> > > generic
> > > CPUs, get_nohz_timer_target() is a problem with things like
> > > tbench.
> >
> > So by isolated CPU you mean those part of isolcpus= boot option,
> > right?
>
> Yes, isolated in the scheduler sense, either via isolcpus= or
> cpusets.
> If the CPU is part of a scheduler domain, it is by definition part
> of
> the generic work crew.
>
> > > tbench 8 with Rik's patches applied:
> > > nohz_full=empty
> > > Throughput 3204.69 MB/sec 1.000
> > > nohz_full=1-3,5-7
> > > Throughput 1354.99 MB/sec .422 1.000
> > > nohz_full=1-3,5-7 + club below
> > > Throughput 2762.22 MB/sec .861 2.038
> > >
> > > With Rik's patches and a club, tbench becomes nearly acceptable.
> > > ---
> > > include/linux/tick.h |2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > --- a/include/linux/tick.h
> > > +++ b/include/linux/tick.h
> > > @@ -184,7 +184,7 @@ static inline const struct cpumask *hous
> > > static inline bool is_housekeeping_cpu(int cpu)
> > > {
> > > #ifdef CONFIG_NO_HZ_FULL
> > > - if (tick_nohz_full_enabled())
> > > + if (tick_nohz_full_enabled() &&
> > > runqueue_is_isolated(cpu))
> > > return cpumask_test_cpu(cpu, housekeeping_mask);
> >
> > This makes me confused. How forcing timers to CPUs in isolcpus is
> > making
> > better results?
>
> It doesn't, it's shutting get_nohz_timer_target() down for those
> nohz_full CPUs that are NOT currently isolated, are thus generic CPUs
> with the capability to _become_ elite solo artists on demand.
Damn, I'm gonna have to ask...
If an isolated elite task sets the alarm, why would it want it to go
off somewhere else, maybe in the middle of a death metal concert?
Seems it must induce jitter. Why is this a good thing?
-Mike
Re: [GIT PULL] (xen) stable/for-jens-4.5
On 01/29/2016 08:11 PM, Konrad Rzeszutek Wilk wrote: Hey Jens, Please git pull the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-4.5 which has one bug-fix. I had it in my tree at some point and after an rebase (done months ago) lost it! It solves an migration problem where the number of queues may differ from one host to another. Pulled, thanks. -- Jens Axboe
Re: [PATCH] block: fix use-after-free in dio_bio_complete
On 01/30/2016 09:09 AM, Mike Krinkin wrote: kasan reported the following error when i ran xfstest: [ 701.826854] == [ 701.826864] BUG: KASAN: use-after-free in dio_bio_complete+0x41a/0x600 at addr 880080b95f94 [ 701.826870] Read of size 4 by task loop2/3874 [ 701.826879] page:ea000202e540 count:0 mapcount:0 mapping: (null) index:0x0 [ 701.826890] flags: 0x100() [ 701.826895] page dumped because: kasan: bad access detected [ 701.826904] CPU: 3 PID: 3874 Comm: loop2 Tainted: GB WL 4.5.0-rc1-next-20160129 #83 [ 701.826910] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013 [ 701.826917] 88008fadf800 88008fadf758 81ca67bb 41b58ab3 [ 701.826941] 830d1e74 81ca6724 88008fadf748 8161c05c [ 701.826963] 0282 88008fadf800 ed0010172bf2 ea000202e540 [ 701.826987] Call Trace: [ 701.826997] [] dump_stack+0x97/0xdc [ 701.827005] [] ? _atomic_dec_and_lock+0xc4/0xc4 [ 701.827014] [] ? __dump_page+0x32c/0x490 [ 701.827023] [] kasan_report_error+0x5f3/0x8b0 [ 701.827033] [] ? dio_bio_complete+0x41a/0x600 [ 701.827040] [] __asan_report_load4_noabort+0x59/0x80 [ 701.827048] [] ? dio_bio_complete+0x41a/0x600 [ 701.827053] [] dio_bio_complete+0x41a/0x600 [ 701.827057] [] ? blk_queue_exit+0x108/0x270 [ 701.827060] [] dio_bio_end_aio+0xa0/0x4d0 [ 701.827063] [] ? dio_bio_complete+0x600/0x600 [ 701.827067] [] ? blk_account_io_completion+0x316/0x5d0 [ 701.827070] [] bio_endio+0x79/0x200 [ 701.827074] [] blk_update_request+0x1df/0xc50 [ 701.827078] [] blk_mq_end_request+0x57/0x120 [ 701.827081] [] __blk_mq_complete_request+0x310/0x590 [ 701.827084] [] ? set_next_entity+0x2f8/0x2ed0 [ 701.827088] [] ? put_prev_entity+0x22d/0x2a70 [ 701.827091] [] blk_mq_complete_request+0x5b/0x80 [ 701.827094] [] loop_queue_work+0x273/0x19d0 [ 701.827098] [] ? finish_task_switch+0x1c8/0x8e0 [ 701.827101] [] ? trace_hardirqs_on_caller+0x18/0x6c0 [ 701.827104] [] ? lo_read_simple+0x890/0x890 [ 701.827108] [] ? debug_check_no_locks_freed+0x350/0x350 [ 701.827111] [] ? __hrtick_start+0x130/0x130 [ 701.827115] [] ? __schedule+0x936/0x20b0 [ 701.827118] [] ? kthread_worker_fn+0x3ed/0x8d0 [ 701.827121] [] ? kthread_worker_fn+0x21d/0x8d0 [ 701.827125] [] ? trace_hardirqs_on_caller+0x18/0x6c0 [ 701.827128] [] kthread_worker_fn+0x2af/0x8d0 [ 701.827132] [] ? __init_kthread_worker+0x170/0x170 [ 701.827135] [] ? _raw_spin_unlock_irqrestore+0x36/0x60 [ 701.827138] [] ? __init_kthread_worker+0x170/0x170 [ 701.827141] [] ? __init_kthread_worker+0x170/0x170 [ 701.827144] [] kthread+0x24b/0x3a0 [ 701.827148] [] ? kthread_create_on_node+0x4c0/0x4c0 [ 701.827151] [] ? trace_hardirqs_on+0xd/0x10 [ 701.827155] [] ? do_group_exit+0xdd/0x350 [ 701.827158] [] ? kthread_create_on_node+0x4c0/0x4c0 [ 701.827161] [] ret_from_fork+0x3f/0x70 [ 701.827165] [] ? kthread_create_on_node+0x4c0/0x4c0 [ 701.827167] Memory state around the buggy address: [ 701.827170] 880080b95e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 701.827172] 880080b95f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 701.827175] >880080b95f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 701.827177] ^ [ 701.827179] 880080b96000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 701.827182] 880080b96080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 701.827183] == The problem is that bio_check_pages_dirty calls bio_put, so we must not access bio fields after bio_check_pages_dirty. Thanks, patch is correct, I have added it. -- Jens Axboe
[PATCHv5 3/3] rdmacg: Added documentation for rdma controller
Added documentation for rdma controller to use in v1 mode and using new unified hirerchy mode v2. Signed-off-by: Parav Pandit --- Documentation/cgroup-v1/rdma.txt | 117 +++ Documentation/cgroup-v2.txt | 43 ++ 2 files changed, 160 insertions(+) create mode 100644 Documentation/cgroup-v1/rdma.txt diff --git a/Documentation/cgroup-v1/rdma.txt b/Documentation/cgroup-v1/rdma.txt new file mode 100644 index 000..688f04b --- /dev/null +++ b/Documentation/cgroup-v1/rdma.txt @@ -0,0 +1,117 @@ + RDMA Controller + + +Contents + + +1. Overview + 1-1. What is RDMA controller? + 1-2. Why RDMA controller needed? + 1-3. How is RDMA controller implemented? +2. Usage Examples + +1. Overview + +1-1. What is RDMA controller? +- + +RDMA controller allows user to limit RDMA/IB specific resources +that a given set of processes can use. These processes are grouped using +RDMA controller. + +RDMA controller currently allows two different type of resource pools. +(a) RDMA IB specification level verb resources defined by IB stack +(b) HCA vendor device specific resources + +1-2. Why RDMA controller needed? + + +Currently user space applications can easily take away all the rdma device +specific resources such as AH, CQ, QP, MR etc. Due to which other applications +in other cgroup or kernel space ULPs may not even get chance to allocate any +rdma resources. This leads to service unavailability. + +Therefore RDMA controller is needed through which resource consumption +of processes can be limited. Through this controller various different rdma +resources described by IB uverbs layer and any HCA vendor driver can be +accounted. + +1-3. How is RDMA controller implemented? + + +RDMA cgroup allows limit configuration of resources. These resources are not +defined by the rdma controller. Instead they are defined by the IB stack +and HCA device drivers(optionally). +This provides great flexibility to allow IB stack to define new resources, +without any changes to rdma cgroup. +Rdma cgroup maintains resource accounting per cgroup, per device, per resource +type using resource pool structure. Each such resource pool is limited up to +64 resources in given resource pool by rdma cgroup, which can be extended +later if required. + +This resource pool object is linked to the cgroup css. Typically there +are 0 to 4 resource pool instances per cgroup, per device in most use cases. +But nothing limits to have it more. At present hundreds of RDMA devices per +single cgroup may not be handled optimally, however there is no known use case +for such configuration either. + +Since RDMA resources can be allocated from any process and can be freed by any +of the child processes which shares the address space, rdma resources are +always owned by the creator cgroup css. This allows process migration from one +to other cgroup without major complexity of transferring resource ownership; +because such ownership is not really present due to shared nature of +rdma resources. Linking resources around css also ensures that cgroups can be +deleted after processes migrated. This allow progress migration as well with +active resources, even though that’s not the primary use case. + +Whenever RDMA resource charing occurs, owner rdma cgroup is returned to +the caller. Same rdma cgroup should be passed while uncharging the resource. +This also allows process migrated with active RDMA resource to charge +to new owner cgroup for new resource. It also allows to uncharge resource of +a process from previously charged cgroup which is migrated to new cgroup, +even though that is not a primary use case. + +Resource pool object is created in following situations. +(a) User sets the limit and no previous resource pool exist for the device +of interest for the cgroup. +(b) No resource limits were configured, but IB/RDMA stack tries to +charge the resource. So that it correctly uncharge them when applications are +running without limits and later on when limits are enforced during uncharging, +otherwise usage count will drop to negative. This is done using default +resource pool. Instead of implementing any sort of time markers, default pool +simplifies the design. + +Resource pool is destroyed if it was of default type (not created +by administrative operation) and it’s the last resource getting +deallocated. Resource pool created as administrative operation is not +deleted, as it’s expected to be used in near future. + +If user setting tries to delete all the resource limit +with active resources per device, RDMA cgroup just marks the pool as +default pool with maximum limits for each resource, otherwise it deletes the +default resource pool. + +2. Usage Examples +- + +(a) Configure resource limit: +echo mlx4_0
[PATCHv5 2/3] IB/core: added support to use rdma cgroup controller
Added support APIs for IB core to register/unregister every RDMA device
with rdma cgroup for tracking verbs and hw resources.
IB core registers with rdma cgroup controller and also defines resources
that can be accounted.
Added support APIs for uverbs layer to make use of rdma controller.
Added uverbs layer to perform resource charge/uncharge functionality.
Signed-off-by: Parav Pandit
---
drivers/infiniband/core/Makefile | 1 +
drivers/infiniband/core/cgroup.c | 138 ++
drivers/infiniband/core/core_priv.h | 45
drivers/infiniband/core/device.c | 8 ++
drivers/infiniband/core/uverbs_cmd.c | 209 +++---
drivers/infiniband/core/uverbs_main.c | 28 +
include/rdma/ib_verbs.h | 27 -
7 files changed, 440 insertions(+), 16 deletions(-)
create mode 100644 drivers/infiniband/core/cgroup.c
diff --git a/drivers/infiniband/core/Makefile b/drivers/infiniband/core/Makefile
index d43a899..df40cee 100644
--- a/drivers/infiniband/core/Makefile
+++ b/drivers/infiniband/core/Makefile
@@ -13,6 +13,7 @@ ib_core-y := packer.o ud_header.o verbs.o
sysfs.o \
roce_gid_mgmt.o
ib_core-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
ib_core-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o umem_rbtree.o
+ib_core-$(CONFIG_CGROUP_RDMA) += cgroup.o
ib_mad-y :=mad.o smi.o agent.o mad_rmpp.o
diff --git a/drivers/infiniband/core/cgroup.c b/drivers/infiniband/core/cgroup.c
new file mode 100644
index 000..2c23cfd
--- /dev/null
+++ b/drivers/infiniband/core/cgroup.c
@@ -0,0 +1,138 @@
+/*
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include
+#include
+#include
+
+#include "core_priv.h"
+
+/**
+ * resource table definition as to be seen by the user.
+ * Need to add entries to it when more resources are
+ * added/defined at IB verb/core layer.
+ */
+static match_table_t resource_tokens = {
+ {RDMA_VERB_RESOURCE_UCTX, "uctx=%d"},
+ {RDMA_VERB_RESOURCE_AH, "ah=%d"},
+ {RDMA_VERB_RESOURCE_PD, "pd=%d"},
+ {RDMA_VERB_RESOURCE_CQ, "cq=%d"},
+ {RDMA_VERB_RESOURCE_MR, "mr=%d"},
+ {RDMA_VERB_RESOURCE_MW, "mw=%d"},
+ {RDMA_VERB_RESOURCE_SRQ, "srq=%d"},
+ {RDMA_VERB_RESOURCE_QP, "qp=%d"},
+ {RDMA_VERB_RESOURCE_FLOW, "flow=%d"},
+ {-1, NULL}
+};
+
+/**
+ * setup table pointers for RDMA cgroup to access.
+ */
+static struct rdmacg_pool_info verbs_token_info = {
+ .resource_table = resource_tokens,
+ .resource_count =
+ (sizeof(resource_tokens) / sizeof(struct match_token)) - 1,
+};
+
+static struct rdmacg_pool_info*
+ rdmacg_get_resource_pool_tokens(struct rdmacg_device *device)
+{
+ return _token_info;
+}
+
+static struct rdmacg_resource_pool_ops verbs_pool_ops = {
+ .get_resource_pool_tokens = _get_resource_pool_tokens,
+};
+
+/**
+ * ib_device_register_rdmacg - register with rdma cgroup.
+ * @device: device to register to participate in resource
+ * accounting by rdma cgroup.
+ *
+ * Register with the rdma cgroup. Should be called before
+ * exposing rdma device to user space applications to avoid
+ * resource accounting leak.
+ * HCA drivers should set resource pool ops first if they wish
+ * to support hw specific resource accounting before IB core
+ * registers with rdma cgroup.
+ */
+void ib_device_register_rdmacg(struct ib_device *device)
+{
+ rdmacg_set_rpool_ops(>cg_device,
+RDMACG_RESOURCE_POOL_VERB,
+_pool_ops);
+ rdmacg_register_device(>cg_device, device->name);
[PATCHv5 1/3] rdmacg: Added rdma cgroup controller.
Added rdma cgroup controller that does accounting, limit enforcement
on rdma/IB verbs and hw resources.
Added rdma cgroup header file which defines its APIs to perform
charing/uncharing functionality and device registration which will
participate in controller functions of accounting and limit
enforcements. It also define rdmacg_device structure to bind IB stack
and RDMA cgroup controller.
RDMA resources are tracked using resource pool. Resource pool is per
device, per cgroup, per resource pool_type entity which allows setting
up accounting limits on per device basis.
RDMA cgroup returns error when user space applications try to allocate
resources more than its configured limit.
Rdma cgroup implements resource accounting for two types of resource
pools.
(a) RDMA IB specification level verb resources defined by IB stack
(b) HCA vendor device specific resources defined by vendor device driver
Resources are not defined by the RDMA cgroup, instead they are defined
by the external module, typically IB stack and optionally by HCA drivers
for those RDMA devices which doesn't have one to one mapping of IB verb
resource with hardware resource. This allows extending IB stack without
changing kernel, which is frequent as IB stack is going through changes
and enhancements.
Resource pool are created/destroyed dynamically whenever
charging/uncharging occurs respectively and whenever user configuration
is done. Its a tradeoff of memory vs little more code space that creates
resource pool whenever necessary, instead of creating them during cgroup
creation and device registration time.
Signed-off-by: Parav Pandit
---
include/linux/cgroup_rdma.h | 78
include/linux/cgroup_subsys.h | 4 +
init/Kconfig | 11 +
kernel/Makefile | 1 +
kernel/cgroup_rdma.c | 994 ++
5 files changed, 1088 insertions(+)
create mode 100644 include/linux/cgroup_rdma.h
create mode 100644 kernel/cgroup_rdma.c
diff --git a/include/linux/cgroup_rdma.h b/include/linux/cgroup_rdma.h
new file mode 100644
index 000..085ece8
--- /dev/null
+++ b/include/linux/cgroup_rdma.h
@@ -0,0 +1,78 @@
+#ifndef _CGROUP_RDMA_H
+#define _CGROUP_RDMA_H
+
+#include
+
+/*
+ * This file is subject to the terms and conditions of version 2 of the GNU
+ * General Public License. See the file COPYING in the main directory of the
+ * Linux distribution for more details.
+ */
+
+enum rdmacg_resource_pool_type {
+ RDMACG_RESOURCE_POOL_VERB,
+ RDMACG_RESOURCE_POOL_HW,
+ RDMACG_RESOURCE_POOL_TYPE_MAX,
+};
+
+struct rdma_cgroup {
+#ifdef CONFIG_CGROUP_RDMA
+ struct cgroup_subsys_state css;
+
+ spinlock_t rpool_list_lock; /* protects resource pool list */
+ struct list_head rpool_head;/* head to keep track of all resource
+* pools that belongs to this cgroup.
+*/
+#endif
+};
+
+#ifdef CONFIG_CGROUP_RDMA
+
+struct rdmacg_device;
+
+struct rdmacg_pool_info {
+ struct match_token *resource_table;
+ int resource_count;
+};
+
+struct rdmacg_resource_pool_ops {
+ struct rdmacg_pool_info*
+ (*get_resource_pool_tokens)(struct rdmacg_device *);
+};
+
+struct rdmacg_device {
+ struct rdmacg_resource_pool_ops
+ *rpool_ops[RDMACG_RESOURCE_POOL_TYPE_MAX];
+ struct list_headrdmacg_list;
+ char*name;
+};
+
+/* APIs for RDMA/IB stack to publish when a device wants to
+ * participate in resource accounting
+ */
+void rdmacg_register_device(struct rdmacg_device *device, char *dev_name);
+void rdmacg_unregister_device(struct rdmacg_device *device);
+
+/* APIs for RDMA/IB stack to charge/uncharge pool specific resources */
+int rdmacg_try_charge(struct rdma_cgroup **rdmacg,
+ struct rdmacg_device *device,
+ enum rdmacg_resource_pool_type type,
+ int resource_index,
+ int num);
+void rdmacg_uncharge(struct rdma_cgroup *cg,
+struct rdmacg_device *device,
+enum rdmacg_resource_pool_type type,
+int resource_index,
+int num);
+
+void rdmacg_set_rpool_ops(struct rdmacg_device *device,
+ enum rdmacg_resource_pool_type pool_type,
+ struct rdmacg_resource_pool_ops *ops);
+void rdmacg_clear_rpool_ops(struct rdmacg_device *device,
+ enum rdmacg_resource_pool_type pool_type);
+int rdmacg_query_limit(struct rdmacg_device *device,
+ enum rdmacg_resource_pool_type type,
+ int *limits, int max_count);
+
+#endif /* CONFIG_CGROUP_RDMA */
+#endif /* _CGROUP_RDMA_H */
diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index 0df0336a..d0e597c 100644
--- a/include/linux/cgroup_subsys.h
+++
[PATCHv5 0/3] rdmacg: IB/core: rdma controller support
This patchset adds support for RDMA cgroup by addressing review comments of [2], [1] and by implementing published RFC [3]. Overview: Currently user space applications can easily take away all the rdma device specific resources such as AH, CQ, QP, MR etc. Due to which other applications in other cgroup or kernel space ULPs may not even get chance to allocate any rdma resources. This results into service unavailibility. RDMA cgroup addresses this issue by allowing resource accounting, limit enforcement on per cgroup, per rdma device basis. Resources are not defined by the RDMA cgroup. Resources are defined by RDMA/IB stack & optionally by HCA vendor device drivers. This allows rdma cgroup to remain constant while RDMA/IB stack can evolve without the need of rdma cgroup update. A new resource can be easily added by the RDMA/IB stack without touching rdma cgroup. RDMA uverbs layer will enforce limits on well defined RDMA verb resources without any HCA vendor device driver involvement. RDMA uverbs layer will not do accounting of hw vendor specific resources. Instead rdma cgroup provides set of APIs through which vendor specific drivers can define their own resources (upto 64) that can be accounted by rdma cgroup. Resource limit enforcement is hierarchical. When process is migrated with active RDMA resources, rdma cgroup continues to uncharge original cgroup for allocated resource. New resource is charged to current process's cgroup, which means if the process is migrated with active resources, for new resources it will be charged to new cgroup and old resources will be correctly uncharged from old cgroup. Changes from v4: * Fixed compilation errors for lockdep_assert_held reported by kbuild test robot * Fixed compilation warning reported by coccinelle for extra semicolon. * Fixed compilation error for inclusion of linux/parser.h which cannot be included in any header file, as that triggers multiple inclusion error. Instead parser.h is included in C files which intent to use it. * Removed unused header file inclusion in cgroup_rdma.c Changes from v3: * (To address comments from Tejun) 1. Renamed cg_resource to rdmacg_resource 2. Merged dealloc_cg_rpool and _dealloc_cg_rpool to single function 3. Renamed _find_cg_rpool to find_cg_rpool_locked() 5. Removed RDMACG_MAX_RESOURCE_INDEX limitation 6. Fixed few alignments. 7. Improved description for RDMA cgroup configuration menu 8. Renamed cg_list_lock to rpool_list_lock to reflect the lock is for rpools. 9. Renamed _get_cg_rpool to find_cg_rpool. 10. Made creator as int variable, instead of atomic as its not required to be atomic. * Fixed freeing right rpool during query_limit error path * Added copywrite for cgroup.c * Removed including parser.h from cgroup.c as its included by cgroup_rdma.h * Reduced try_charge functions to single function and removed duplicate comments. Changes from v2: * Fixed compilation error reported by 0-DAY kernel test infrastructure for m68k architecture where CONFIG_CGROUP is also not defined. * Fixed comment in patch to refer to legacy mode of cgroup, changed to refer to v1 and v2 version. * Added more information in commit log for rdma controller patch. Changes from v1: * (To address comments from Tejun) a. reduces 3 patches to single patch b. removed resource word from the cgroup configuration files c. changed cgroup configuration file names to match other cgroups d. removed .list file and merged functionality with .max file * Based on comment to merge to single patch for rdma controller; IB/core patches are reduced to single patch. * Removed pid cgroup map and simplified design - Charge/Uncharge caller stack keeps track of the rdmacg for given resource. This removes the need to maintain and perform hash lookup. This also allows little more accurate resource charging/uncharging when process moved from one to other cgroup with active resources and continue to allocate more. * Critical fix: Removed rdma cgroup's dependency on the kernel module header files to avoid crashes when modules are upgraded without kernel upgrade, which is very common due to high amount of changes in IB stack and it is also shipped as individual kernel modules. * uboject extended to keep track of the owner rdma cgroup, so that same rdmacg can be used while uncharging. * Added support functions to hide details of rdmacg device in uverbs modules for cases of cgroup enabled/disabled at compile time. This avoids multiple ifdefs for every API in uverbs layer. * Removed failure counters in first patch, which will be added once initial feature is merged. * Fixed stale rpool access which is getting freed, while doing configuration to rdma.verb.max file. * Fixed rpool resource leak while querying max, current values. Changes from v0: (To address comments from Haggai, Doug, Liran, Tejun, Sean, Jason) * Redesigned to support
Re: [PATCH 12/14] ARM: dts: sun8i-a83t: Add RSB nodes to dtsi
Hi,
On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
wrote:
> This adds support for RSB
> A83T RSB is compatible with A23 rsb.
>
> Signed-off-by: Vishnu Patekar
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 11be9e1..8c67c85 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -499,5 +499,19 @@
> allwinner,pull = ;
> };
> };
> +
> + r_rsb: i2c@01f03400 {
> + compatible = "allwinner,sun8i-a23-rsb";
> + reg = <0x01f03400 0x400>;
> + interrupts = ;
> + clocks = <_gates 3>;
> + clock-frequency = <300>;
> + resets = <_reset 3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_rsb_pins>;
As mentioned in the previous patch, r_rsb_pins should be included in this patch,
since it is used here. In general, we mostly have them as individual patches, as
they are referenced from board dts files. Here since it's used in the dtsi, you
can just include them.
See commit ed473ebd9c15 ("ARM: dts: sun9i: Add Reduced Serial Bus controller
device node to A80 dtsi") on how I described it.
ChenYu
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> };
> };
> --
> 1.9.1
>
Re: [PATCH 11/14] ARM: dts: sun8i-a83t: Add R_PIO controller node to the dtsi
On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
wrote:
> Now that we have a driver for the R_PIO controller,
> add the corresponding device node to the dtsi.
>
> Signed-off-by: Vishnu Patekar
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 5ea20ff..11be9e1 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -478,5 +478,26 @@
> compatible = "allwinner,sun6i-a31-clock-reset";
> #reset-cells = <1>;
> };
> +
> + r_pio: pinctrl@01f02c00 {
> + compatible = "allwinner,sun8i-a83t-r-pinctrl";
> + reg = <0x01f02c00 0x400>;
> + interrupts = ;
> + clocks = <_gates 0>;
> + resets = <_reset 0>;
> + gpio-controller;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
#address-cells and #size-cells aren't needed. They were incorrectly included
in the first place. They were removed from but not _pio.
> + #gpio-cells = <3>;
> +
> + r_rsb_pins: r_rsb {
> + allwinner,pins = "PL0", "PL1";
> + allwinner,function = "s_rsb";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
This setting should be part of the next patch, the RSB node patch.
The rest looks fine.
ChenYu
> + };
> };
> };
> --
> 1.9.1
>
Re: [PATCH net-next] netfilter: nf_conntrack: remove the unneed check for *bucket
On 2016/1/31 5:30, Florian Westphal wrote:
> Weidong Wang wrote:
>> In the 'for(...) {}', the *bucket alwasy < net->ct.htable_size,
>> so remove the check
>> @@ -1383,14 +1383,12 @@ get_next_corpse(struct net *net, int (*iter)(struct
>> nf_conn *i, void *data),
>> lockp = _conntrack_locks[*bucket % CONNTRACK_LOCKS];
>> local_bh_disable();
>> spin_lock(lockp);
>> -if (*bucket < net->ct.htable_size) {
>
> AFAIU net->ct.htable_size can shrink between for-test and aquiring
> the bucket lockp, so this additional if-test is needed.
>
ok, Got it.
So ignore this patch.
Regards,
Weidong
> .
>
Re: [PATCH 05/14] clk: sunxi: Add APB1 clock for A83T
On Sun, Jan 31, 2016 at 9:20 AM, Vishnu Patekar
wrote:
> APB1 is similar to sun4i-a10-apb0-clk, except different dividers.
>
> This adds support for apb1 on A83T.
>
> Signed-off-by: Vishnu Patekar
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
> drivers/clk/sunxi/clk-sunxi.c | 17 +
> 2 files changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
> b/Documentation/devicetree/bindings/clock/sunxi.txt
> index bfd82f1..10637e7 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -49,6 +49,7 @@ Required properties:
> "allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
> "allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
> "allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
> + "allwinner,sun8i-a83t-apb1-clk" - for the APB1 clock on A83T
> "allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
> "allwinner,sun4i-a10-apb1-gates-clk" - for the APB1 gates on A10
> "allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 02bbdf6..6510b0e 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -772,6 +772,22 @@ static const struct div_data sun4i_apb0_data __initconst
> = {
> .table = sun4i_apb0_table,
> };
>
> +
> +static const struct clk_div_table sun8i_a83t_apb1_table[] __initconst = {
> + { .val = 0, .div = 1 },
> + { .val = 1, .div = 2 },
> + { .val = 2, .div = 3 },
> + { .val = 3, .div = 4 },
> + { } /* sentinel */
> +};
The table is only needed if it cannot be handled by default or with
the div flags,
such as dividers not increasing or not power-of-2.
ChenYu
> +static const struct div_data sun8i_a83t_apb1_data __initconst = {
> + .shift = 8,
> + .pow= 0,
> + .width = 2,
> + .table = sun8i_a83t_apb1_table,
> +};
> +
> static void __init sunxi_divider_clk_setup(struct device_node *node,
>struct div_data *data)
> {
> @@ -1027,6 +1043,7 @@ static const struct of_device_id clk_div_match[]
> __initconst = {
> {.compatible = "allwinner,sun8i-a23-axi-clk", .data =
> _a23_axi_data,},
> {.compatible = "allwinner,sun4i-a10-ahb-clk", .data =
> _ahb_data,},
> {.compatible = "allwinner,sun4i-a10-apb0-clk", .data =
> _apb0_data,},
> + {.compatible = "allwinner,sun8i-a83t-apb1-clk", .data =
> _a83t_apb1_data,},
> {}
> };
>
> --
> 1.9.1
>
Re: [PATCH 01/14] pinctrl: sunxi: Add A83T R_PIO controller support
Hi,
On Sun, Jan 31, 2016 at 9:20 AM, Vishnu Patekar
wrote:
> The A83T has R_PIO pin controller, it's same as A23, execpt A83T
> interrupt bit is 6th and A83T has one extra pin PL12.
>
> Signed-off-by: Vishnu Patekar
> ---
> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
> drivers/pinctrl/sunxi/Kconfig | 5 +
> drivers/pinctrl/sunxi/Makefile | 1 +
> drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c | 119
> +
> 4 files changed, 126 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c
>
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> index 9213b27..f9ff10b 100644
> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> @@ -20,6 +20,7 @@ Required properties:
>"allwinner,sun9i-a80-pinctrl"
>"allwinner,sun9i-a80-r-pinctrl"
>"allwinner,sun8i-a83t-pinctrl"
> + "allwinner,sun8i-a83t-r-pinctrl"
>"allwinner,sun8i-h3-pinctrl"
>
> - reg: Should contain the register physical address and length for the
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index f8dbc8b..c0e4a8b 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -46,6 +46,11 @@ config PINCTRL_SUN8I_A83T
> def_bool MACH_SUN8I
> select PINCTRL_SUNXI_COMMON
>
> +config PINCTRL_SUN8I_A83T_R
> + def_bool MACH_SUN8I
> + depends on RESET_CONTROLLER
> + select PINCTRL_SUNXI_COMMON
> +
Keep them sorted please.
Otherwise,
Acked-by: Chen-Yu Tsai
> config PINCTRL_SUN8I_A23_R
> def_bool MACH_SUN8I
> depends on RESET_CONTROLLER
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index ef82f22..bfd4fa0 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23) +=
> pinctrl-sun8i-a23.o
> obj-$(CONFIG_PINCTRL_SUN8I_A23_R) += pinctrl-sun8i-a23-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_A33)+= pinctrl-sun8i-a33.o
> obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o
> +obj-$(CONFIG_PINCTRL_SUN8I_A83T_R) += pinctrl-sun8i-a83t-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80)+= pinctrl-sun9i-a80.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80_R) += pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c
> b/drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c
> new file mode 100644
> index 000..11787894
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c
> @@ -0,0 +1,119 @@
> +/*
> + * Allwinner A83T SoCs special pins pinctrl driver.
> + *
> + * Copyright (C) 2016 Vishnu Patekar
> + * Vishnu Patekar
> + *
> + * Based on pinctrl-sun8i-a23.c, which is:
> + * Copyright (C) 2014 Chen-Yu Tsai
> + * Copyright (C) 2014 Maxime Ripard
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin sun8i_a83t_r_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_rsb"), /* SCK */
> + SUNXI_FUNCTION(0x3, "s_twi"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PL_EINT0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_rsb"), /* SDA */
> + SUNXI_FUNCTION(0x3, "s_twi"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /* PL_EINT1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_uart"),/* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)), /* PL_EINT2 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_uart"),/* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)), /* PL_EINT3 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> +
[PATCH] psmouse: added BYD touchpad driver
This adds proper single-touch support for BYD touchpads to the psmouse input driver. This patch is against commit b82dde0230439215b55e545880e90337ee16f51a (Merge tag 'please-pull-copy_file_range' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux ) of Linus' kernel branch. Signed-off-by: Richard Pospesel --- Kconfig|9 Makefile |1 byd.c | 586 + byd.h | 33 +++ psmouse-base.c | 17 + psmouse.h |1 6 files changed, 647 insertions(+) diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig index 17f97e5..63d5349 100644 --- a/drivers/input/mouse/Kconfig +++ b/drivers/input/mouse/Kconfig @@ -161,6 +161,15 @@ config MOUSE_PS2_VMMOUSE If unsure, say N. +config MOUSE_PS2_BYD + bool "BYD PS/2 protocol extension" + depends on MOUSE_PS2 + help + Say Y here if you have a BYD PS/2 touchpad + connected to your system. + + If unsure, say N. + config MOUSE_SERIAL tristate "Serial mouse" select SERIO diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile index ee6a6e9..67f22cc 100644 --- a/drivers/input/mouse/Makefile +++ b/drivers/input/mouse/Makefile @@ -37,6 +37,7 @@ psmouse-$(CONFIG_MOUSE_PS2_TRACKPOINT) += trackpoint.o psmouse-$(CONFIG_MOUSE_PS2_TOUCHKIT) += touchkit_ps2.o psmouse-$(CONFIG_MOUSE_PS2_CYPRESS) += cypress_ps2.o psmouse-$(CONFIG_MOUSE_PS2_VMMOUSE) += vmmouse.o +psmouse-$(CONFIG_MOUSE_PS2_BYD) += byd.o elan_i2c-objs := elan_i2c_core.o elan_i2c-$(CONFIG_MOUSE_ELAN_I2C_I2C) += elan_i2c_i2c.o diff --git a/drivers/input/mouse/byd.c b/drivers/input/mouse/byd.c new file mode 100644 index 000..a880adb --- /dev/null +++ b/drivers/input/mouse/byd.c @@ -0,0 +1,586 @@ +/* + * BYD BTP-10463 touchpad PS/2 mouse driver + * + * Copyright (C) 2015, Tai Chi Minh Ralph Eastwood + * Copyright (C) 2015, Martin Wimpress + * Copyright (C) 2015, Jay Kuri + * Copyright (C) 2015, Richard Pospesel + * + * 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. + * + * Protocol of BYD Touch Pad reverse-engineered from windows driver: + * filename: "byd touchpad driver - win7, 8, 8.1 - 2.4.1.102.zip" + * sha1: 97a0eca8edc482bf9d08ab9509084a514dad4c4b + * datasheet: http://bydit.com/userfiles/file/BTP10463-XXX.pdf + * + */ +#include +#include + +#include +#include +#include +#include + +#include "psmouse.h" +#include "byd.h" + +#define BYD_MODEL_ID_LEN2 +#define BYD_CMD_PAIR(c) ((1 << 12) | (c)) +#define BYD_CMD_PAIR_R(r, c) ((1 << 12) | (r << 8) | (c)) + +/* BYD pad constants */ + +/* + * true device resolution is unknown, however experiments show the + * resolution is about 111 units/mm + * absolute coordinate packets are in the range 0-255 for both X and y + * we pick ABS_X/ABS_Y dimensions which are multiples of 256 and in + * the right ballpark given the touchpad's physical dimensions and estimate + * resolution per spec sheet, device active area dimensions are + * 101.6 x 60.1 mm + */ + +#define BYD_CONST_PAD_WIDTH 11264 +#define BYD_CONST_PAD_HEIGHT6656 +#define BYD_CONST_PAD_RESOLUTION111 + + +/* BYD commands reverse engineered from windows driver */ + +/* + * swipe gesture from off-pad to on-pad + * 0 : disable + * 1 : enable + */ +#define BYD_CMD_SET_OFFSCREEN_SWIPE 0xcc +/* + * tap and drag delay time + * 0 : disable + * 1 - 8 : least to most delay + */ +#define BYD_CMD_SET_TAP_DRAG_DELAY_TIME 0xcf +/* + * physical buttons function mapping + * 0 : enable + * 4 : normal + * 5 : left button custom command + * 6 : right button custom command + * 8 : disable + */ +#define BYD_CMD_SET_PHYSICAL_BUTTONS0xd0 +/* + * absolute mode (1 byte X/Y resolution) + * 0 : disable + * 2 : enable + */ +#define BYD_CMD_SET_ABSOLUTE_MODE 0xd1 +/* + * two finger scrolling + * 1 : vertical + * 2 : horizontal + * 3 : vertical + horizontal + * 4 : disable + */ +#define BYD_CMD_SET_TWO_FINGER_SCROLL 0xd2 +/* + * handedness + * 1 : right handed + * 2 : left handed + */ +#define BYD_CMD_SET_HANDEDNESS 0xd3 +/* + * tap to click + * 1 : enable + * 2 : disable + */ +#define BYD_CMD_SET_TAP 0xd4 +/* + * tap and drag + * 1 : tap and hold to drag + * 2 : tap and hold to drag + lock + * 3 : disable + */ +#define BYD_CMD_SET_TAP_DRAG0xd5 +/* + * touch sensitivity + * 1 - 7 : least to most sensitive + */ +#define BYD_CMD_SET_TOUCH_SENSITIVITY 0xd6 +/* + * one finger scrolling + * 1 : vertical + * 2 : horizontal + * 3 : vertical + horizontal + * 4 : disable + */ +#define BYD_CMD_SET_ONE_FINGER_SCROLL 0xd7 +/* + * one finger scrolling function + * 1 : free scrolling + * 2 : edge motion + * 3 : free scrolling + edge
Re: [PATCH 2/2] sigaltstack: remove EPERM check to make swapcontext() usable
[re-sending with better formatting]
09.01.2016 05:49, Stas Sergeev пишет:
09.01.2016 05:03, Andy Lutomirski пишет:
On Fri, Jan 8, 2016 at 5:18 PM, Stas Sergeev wrote:
linux implements the sigaltstack() in a way that makes it
>>> impossible to
>>> use with swapcontext(). Per the man page, sigaltstack is allowed to
>>> return
>>> EPERM if the process is altering its sigaltstack while running on
>>> sigaltstack.
>>> This is likely needed to consistently return oss->ss_flags, that
>>> indicates
>>> whether the process is being on sigaltstack or not.
>>> Unfortunately, linux takes that permission to return EPERM too
>>> literally:
>>> it returns EPERM even if you don't want to change to another
>>> sigaltstack,
>>> but only want to disable sigaltstack with SS_DISABLE.
>>> You can't use swapcontext() without disabling sigaltstack first, or
>>> the
>>> stack will be re-used and overwritten by a subsequent signal.
>>> With this patch, disabling sigaltstack inside a signal handler
>>> became
>>> possible, and the swapcontext() can then be used safely. The
>>> oss->ss_flags
>>> will then return SS_DISABLE, which doesn't seem to contradict the
>>> (very ambiguous) man page wording, namely:
>>> SS_ONSTACK
>>>The process is currently executing on the alternate
>>> signal
>>>stack. (Note that it is not possible to change the
>>> alternate
>>>signal stack if the process is currently executing
>>> on it.)
>>>
>> You're definitely contradicting the "Note" part, though. POSIX is
>> quite clear, too:
>> "Attempts to modify the alternate signal stack while the process is
>> executing on it fail."
> "modify" may not include "disable".
> You don't modify the stack's location or size, just temporary disable
> its use.
> So I believe SS_DISABLE should be fine.
> Of course this is just one of the possible interpretations.
> But it is the one that looks simple and satisfies everyone.
I've finally made the patch to demonstrate that.
It has the nasty disadvantage of touching the arch-specific
code, but it has the advantages too:
- seems compatible with both posix and swapcontext()
(before using swapcontext() in a sighandler, the sigaltstack
have to be disabled - this is what this patch makes possible)
- doesn't require the new flag to paper around one of the
possible posix interpretation
- consistently returns oss->ss_flags==SS_ONSTACK while in
sighandler, even after setting flags to SS_DISABLE
- allows someone (like glibc), if need be, to implement the old
behaviour: it can check for oss->ss_flags first, and if it is
SS_ONSTACK, return EPERM without trying to set the new value.
So since this patch demonstrates the way of solving the
swapcontext() problem without adding the SS_FORCE flag
to sigaltstack(), I believe we shouldn't be adding it. That flag
will only allow us to have a smaller patch that doesn't touch
the arch code, but is that a good enough justification?
So if there are no objections, I'll probably have to add an
arch-specific ifdefs to this patch to make other arches
unaffected, and submit it.
Of course we can still just remove the EPERM check.
Thoughts?
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index cb6282c..06e2591 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -216,7 +216,7 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs
*regs, size_t frame_size,
if (!onsigstack) {
/* This is the X/Open sanctioned signal stack switching. */
if (ka->sa.sa_flags & SA_ONSTACK) {
-if (current->sas_ss_size)
+if (sas_ss_enabled())
sp = current->sas_ss_sp + current->sas_ss_size;
} else if (config_enabled(CONFIG_X86_32) &&
(regs->ss & 0x) != __USER_DS &&
diff --git a/include/linux/sched.h b/include/linux/sched.h
index edad7a4..f7e7026 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1572,6 +1572,7 @@ struct task_struct {
unsigned long sas_ss_sp;
size_t sas_ss_size;
+int sas_ss_flags;
struct callback_head *task_works;
@@ -2550,8 +2551,16 @@ static inline int sas_ss_flags(unsigned long sp)
{
if (!current->sas_ss_size)
return SS_DISABLE;
+if (on_sig_stack(sp))
+return SS_ONSTACK;
+if (current->sas_ss_flags == SS_DISABLE)
+return SS_DISABLE;
+return 0;
+}
-return on_sig_stack(sp) ? SS_ONSTACK : 0;
+static inline int sas_ss_enabled(void)
+{
+return (current->sas_ss_size && current->sas_ss_flags != SS_DISABLE);
}
static inline unsigned long sigsp(unsigned long sp, struct ksignal *ksig)
diff --git a/include/linux/signal.h b/include/linux/signal.h
index 92557bb..844b113 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -432,7 +432,7 @@ int __save_altstack(stack_t __user *, unsigned long);
stack_t __user *__uss = uss; \
struct task_struct *t = current; \
put_user_ex((void __user *)t->sas_ss_sp,
Re: [PATCH 2/2] sched,time: call __acct_update_integrals once a jiffy
On Sat, 2016-01-30 at 21:36 +0100, Frederic Weisbecker wrote:
> On Sat, Jan 30, 2016 at 06:53:05PM +0100, Mike Galbraith wrote:
> > On Sat, 2016-01-30 at 15:20 +0100, Frederic Weisbecker wrote:
> > > On Fri, Jan 29, 2016 at 05:43:28PM -0500, Rik van Riel wrote:
> >
> > > > Run times for the microbenchmark:
> > > >
> > > > 4.4 3.8 seconds
> > > > 4.5-rc1 3.7 seconds
> > > > 4.5-rc1 + first patch 3.3 seconds
> > > > 4.5-rc1 + both patches 2.3 seconds
> > >
> > > Very nice improvement!
> >
> > Tasty indeed.
> >
> > When nohz_full CPUs are not isolated, ie are being used as generic
> > CPUs, get_nohz_timer_target() is a problem with things like tbench.
>
> So by isolated CPU you mean those part of isolcpus= boot option,
> right?
Yes, isolated in the scheduler sense, either via isolcpus= or cpusets.
If the CPU is part of a scheduler domain, it is by definition part of
the generic work crew.
> > tbench 8 with Rik's patches applied:
> > nohz_full=empty
> > Throughput 3204.69 MB/sec 1.000
> > nohz_full=1-3,5-7
> > Throughput 1354.99 MB/sec .422 1.000
> > nohz_full=1-3,5-7 + club below
> > Throughput 2762.22 MB/sec .861 2.038
> >
> > With Rik's patches and a club, tbench becomes nearly acceptable.
> > ---
> > include/linux/tick.h |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- a/include/linux/tick.h
> > +++ b/include/linux/tick.h
> > @@ -184,7 +184,7 @@ static inline const struct cpumask *hous
> > static inline bool is_housekeeping_cpu(int cpu)
> > {
> > #ifdef CONFIG_NO_HZ_FULL
> > - if (tick_nohz_full_enabled())
> > + if (tick_nohz_full_enabled() && runqueue_is_isolated(cpu))
> > return cpumask_test_cpu(cpu, housekeeping_mask);
>
> This makes me confused. How forcing timers to CPUs in isolcpus is making
> better results?
It doesn't, it's shutting get_nohz_timer_target() down for those
nohz_full CPUs that are NOT currently isolated, are thus generic CPUs
with the capability to _become_ elite solo artists on demand.
-Mike
Re: [PATCH 2/2] sigaltstack: remove EPERM check to make swapcontext() usable
09.01.2016 05:49, Stas Sergeev пишет:
09.01.2016 05:03, Andy Lutomirski пишет: >> On Fri, Jan 8, 2016 at 5:18 PM, Stas Sergeev wrote:
>>> linux implements the sigaltstack() in a way that makes it
impossible to >>> use with swapcontext(). Per the man page, sigaltstack
is allowed to return >>> EPERM if the process is altering its
sigaltstack while running on >>> sigaltstack. >>> This is likely needed
to consistently return oss->ss_flags, that indicates >>> whether the
process is being on sigaltstack or not. >>> Unfortunately, linux takes
that permission to return EPERM too literally: >>> it returns EPERM even
if you don't want to change to another sigaltstack, >>> but only want to
disable sigaltstack with SS_DISABLE. >>> You can't use swapcontext()
without disabling sigaltstack first, or the >>> stack will be re-used
and overwritten by a subsequent signal. >>> >>> With this patch,
disabling sigaltstack inside a signal handler became >>> possible, and
the swapcontext() can then be used safely. The oss->ss_flags >>> will
then return SS_DISABLE, which doesn't seem to contradict the >>> (very
ambiguous) man page wording, namely: >>> SS_ONSTACK
>>>The process is currently executing on the alternate
signal >>>stack. (Note that it is not possible to change
the alternate >>>signal stack if the process is
currently executing on it.) >> You're definitely contradicting the
"Note" part, though. POSIX is >> quite clear, too: >> >> "Attempts to
modify the alternate signal stack while the process is >> executing on
it fail." > "modify" may not include "disable". > You don't modify the
stack's location or size, just temporary disable its use. > So I believe
SS_DISABLE should be fine. > Of course this is just one of the possible
interpretations. > But it is the one that looks simple and satisfies
everyone.
I've finally made the patch to demonstrate that.
It has the nasty disadvantage of touching the arch-specific
code, but it has the advantages too:
- seems compatible with both posix and swapcontext()
(before using swapcontext() in a sighandler, the sigaltstack
have to be disabled - this is what this patch makes possible)
- doesn't require the new flag to paper around one of the
possible posix interpretation
- consistently returns oss->ss_flags==SS_ONSTACK while in
sighandler, even after setting flags to SS_DISABLE
- allows someone (like glibc), if need be, to implement the old
behaviour: it can check for oss->ss_flags first, and if it is
SS_ONSTACK, return EPERM without trying to set the new value.
So since this patch demonstrates the way of solving the
swapcontext() problem without adding the SS_FORCE flag
to sigaltstack(), I believe we shouldn't be adding it. That flag
will only allow us to have a smaller patch that doesn't touch
the arch code, but is that a good enough justification?
So if there are no objections, I'll probably have to add an
arch-specific ifdefs to this patch to make other arches
unaffected, and submit it.
Of course we can still just remove the EPERM check.
Thoughts?
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index cb6282c..06e2591 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -216,7 +216,7 @@ get_sigframe(struct k_sigaction *ka, struct pt_regs
*regs, size_t frame_size,
if (!onsigstack) {
/* This is the X/Open sanctioned signal stack switching. */
if (ka->sa.sa_flags & SA_ONSTACK) {
-if (current->sas_ss_size)
+if (sas_ss_enabled())
sp = current->sas_ss_sp + current->sas_ss_size;
} else if (config_enabled(CONFIG_X86_32) &&
(regs->ss & 0x) != __USER_DS &&
diff --git a/include/linux/sched.h b/include/linux/sched.h
index edad7a4..f7e7026 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1572,6 +1572,7 @@ struct task_struct {
unsigned long sas_ss_sp;
size_t sas_ss_size;
+int sas_ss_flags;
struct callback_head *task_works;
@@ -2550,8 +2551,16 @@ static inline int sas_ss_flags(unsigned long sp)
{
if (!current->sas_ss_size)
return SS_DISABLE;
+if (on_sig_stack(sp))
+return SS_ONSTACK;
+if (current->sas_ss_flags == SS_DISABLE)
+return SS_DISABLE;
+return 0;
+}
-return on_sig_stack(sp) ? SS_ONSTACK : 0;
+static inline int sas_ss_enabled(void)
+{
+return (current->sas_ss_size && current->sas_ss_flags != SS_DISABLE);
}
static inline unsigned long sigsp(unsigned long sp, struct ksignal *ksig)
diff --git a/include/linux/signal.h b/include/linux/signal.h
index 92557bb..844b113 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -432,7 +432,7 @@ int __save_altstack(stack_t __user *, unsigned long);
stack_t __user *__uss = uss; \
struct task_struct *t = current; \
put_user_ex((void __user *)t->sas_ss_sp, &__uss->ss_sp); \
-
Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences
On Fri, Jan 29, 2016 at 10:01:13PM -0800, Dan Williams wrote:
> On Fri, Jan 29, 2016 at 9:28 PM, Matthew Wilcox wrote:
> > If we store the PFN of the underlying page instead, we don't have this
> > problem. Instead, we have a different problem; of the device going
> > away under us. I'm trying to find the code which tears down PTEs when
> > the device goes away, and I'm not seeing it. What do we do about user
> > mappings of the device?
>
> I deferred the dax tear down code until next cycle as Al rightly
> pointed out some needed re-works:
>
> https://lists.01.org/pipermail/linux-nvdimm/2016-January/003995.html
Thanks; I eventually found it in my email somewhere over the Pacific.
I did probably 70% of the work needed to switch the radix tree over to
storing PFNs instead of sectors. It seems viable, though it's a big
change from where we are today:
fs/dax.c | 415 +++--
include/linux/dax.h| 3 +-
include/linux/pfn_t.h | 33 +++-
include/linux/radix-tree.h | 9 -
4 files changed, 236 insertions(+), 224 deletions(-)
I'll try and get that finished off this week.
One concrete and easily-separable piece is that dax_clear_blocks() has
the wrong signature. It currently takes an inode & block as parameters;
it has no way of finding out the correct block device. It's only two
callers are filesystems (ext2 and xfs). Those filesystems should be
passing the block_device instead of the inode. But without the inode,
we can't convert a block number to a sector number, so we also need
to pass the sector number, not the block number. It still has type
sector_t, annoyingly.
@@ -63,12 +238,11 @@ static void dax_unmap_atomic(struct block_device *bdev,
* and hence this means the stack from this point must follow GFP_NOFS
* semantics for all operations.
*/
-int dax_clear_blocks(struct inode *inode, sector_t block, long _size)
+int dax_clear_blocks(struct block_device *bdev, sector_t sector, long size)
{
- struct block_device *bdev = inode->i_sb->s_bdev;
struct blk_dax_ctl dax = {
- .sector = block << (inode->i_blkbits - 9),
- .size = _size,
+ .sector = sector,
+ .size = size,
};
might_sleep();
but I haven't looked at doing the conversion of xfs or ext2 to use that
new interface.
Re: [slab] a1fd55538c: WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2601 trace_hardirqs_on_caller()
Hi Jesper, On Sat, 30 Jan 2016 18:46:46 +0100 Jesper Dangaard Brouer wrote: > > Let me know, if the linux-next tree need's an explicit fix? It would be a good idea if you could send a fix against linux-next to me as Andrew is currently travelling. -- Cheers, Stephen Rothwell
[PATCH] tpm: fix rollback/cleanup before tpm_chip_register()
The release-callback is not used before the device is attached to the
device hierarchy. This caused resources not to cleanup properly if the
device driver initialization failed before tpm_chip_register().
This patch fixes the issue by adding the cleanup function to the devres
list of the platform device in tpmm_chip_alloc().
Fixes: 313d21eeab ("tpm: device class for tpm")
Signed-off-by: Jarkko Sakkinen
cc: sta...@vger.kernel.org
---
drivers/char/tpm/tpm-chip.c | 43 ---
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 1a9dcee..cf2b351 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -75,16 +75,15 @@ static void tpm_dev_release(struct device *dev)
}
/**
- * tpmm_chip_alloc() - allocate a new struct tpm_chip instance
- * @dev: device to which the chip is associated
+ * tpmm_chip_alloc() - allocate and initialize a TPM chip
+ * @pdev: the platform device who is the parent of the chip
* @ops: struct tpm_class_ops instance
*
- * Allocates a new struct tpm_chip instance and assigns a free
- * device number for it. Caller does not have to worry about
- * freeing the allocated resources. When the devices is removed
- * devres calls tpmm_chip_remove() to do the job.
+ * Allocates a new struct tpm_chip instance, prepares the character device and
+ * assigns a free device number for it. The memory is freed automatically when
+ * the platform device is detached.
*/
-struct tpm_chip *tpmm_chip_alloc(struct device *dev,
+struct tpm_chip *tpmm_chip_alloc(struct device *pdev,
const struct tpm_class_ops *ops)
{
struct tpm_chip *chip;
@@ -103,7 +102,7 @@ struct tpm_chip *tpmm_chip_alloc(struct device *dev,
spin_unlock(_lock);
if (chip->dev_num >= TPM_NUM_DEVICES) {
- dev_err(dev, "No available tpm device numbers\n");
+ dev_err(pdev, "No available tpm device numbers\n");
kfree(chip);
return ERR_PTR(-ENOMEM);
}
@@ -112,9 +111,7 @@ struct tpm_chip *tpmm_chip_alloc(struct device *dev,
scnprintf(chip->devname, sizeof(chip->devname), "tpm%d", chip->dev_num);
- chip->pdev = dev;
-
- dev_set_drvdata(dev, chip);
+ chip->pdev = pdev;
chip->dev.class = tpm_class;
chip->dev.release = tpm_dev_release;
@@ -136,6 +133,12 @@ struct tpm_chip *tpmm_chip_alloc(struct device *dev,
chip->cdev.owner = chip->pdev->driver->owner;
chip->cdev.kobj.parent = >dev.kobj;
+ /* Associate character device with the platform device only after
+* it is properly initialized.
+*/
+ dev_set_drvdata(pdev, chip);
+ devm_add_action(pdev, (void (*)(void *)) tpm_dev_release, >dev);
+
return chip;
}
EXPORT_SYMBOL_GPL(tpmm_chip_alloc);
@@ -162,7 +165,10 @@ static int tpm_add_char_device(struct tpm_chip *chip)
MINOR(chip->dev.devt), rc);
cdev_del(>cdev);
- return rc;
+ } else {
+ devm_remove_action(chip->dev.parent,
+ (void (*)(void *)) tpm_dev_release,
+ >dev);
}
return rc;
@@ -202,15 +208,14 @@ static void tpm1_chip_unregister(struct tpm_chip *chip)
}
/*
- * tpm_chip_register() - create a character device for the TPM chip
- * @chip: TPM chip to use.
+ * tpm_chip_register() - add a TPM chip to the device hierarchy
+ * @chip: the TPM chip to be added
*
- * Creates a character device for the TPM chip and adds sysfs attributes for
- * the device. As the last step this function adds the chip to the list of TPM
- * chips available for in-kernel use.
+ * Adds a TPM chip to the device hierarchy and makes it available to for
+ * in-kernel use.
*
- * This function should be only called after the chip initialization is
- * complete.
+ * This function should be called only after the device driver is otherwise
+ * initialized because it will become available for client access.
*/
int tpm_chip_register(struct tpm_chip *chip)
{
--
2.7.0
Re: 4.5-rc1: mm/gup.c warning when writing to /proc/self/mem
On Sat, 30 Jan 2016, Kirill A. Shutemov wrote:
> On Sat, Jan 30, 2016 at 12:58:31PM -0500, Dave Jones wrote:
> > Hit this overnight. Just started seeing this after I added "create mmap's
> > of fd's we open()'d" to trinity.
>
> The WARN_ON_ONCE() came form Hugh's patch:
> cda540ace6a1 ("mm: get_user_pages(write,force) refuse to COW in shared
> areas")
>
> This warning is expected if you try to write via /proc//mem into
> write-protected shared mapping without FMODE_WRITE on the underlying file.
Other way round: it happens only when you do have FMODE_WRITE on the file.
It was always a strange case.
> You're not supposed to do that and -EFAULT is right answer for an attempt.
>
> The WARN_ON_ONCE() was added almost two years ago to catch other not
> expected users of get_user_pages(write=1,force=1). IIUC, none were found.
>
> Probably we should consider removing the warning.
Yes, I agree: as a _ONCE, it doesn't do a whole lot of harm,
but we just don't need it any longer. And it reminds me of
something else you pointed out to me back then...
>
> >
> > Dave
> >
> > WARNING: CPU: 1 PID: 16733 at mm/gup.c:434 __get_user_pages+0x5f9/0x990()
[PATCH] mm: retire GUP WARN_ON_ONCE that outlived its usefulness
Trinity is now hitting the WARN_ON_ONCE we added in v3.15 commit
cda540ace6a1 ("mm: get_user_pages(write,force) refuse to COW in shared
areas"). The warning has served its purpose, nobody was harmed by that
change, so just remove the warning to generate less noise from Trinity.
Which reminds me of the comment I wrongly left behind with that commit
(but was spotted at the time by Kirill), which has since moved into a
separate function, and become even more obscure: delete it.
Reported-by: Dave Jones
Suggested-by: Kirill A. Shutemov
Signed-off-by: Hugh Dickins
---
mm/gup.c|4 +---
mm/memory.c |5 -
2 files changed, 1 insertion(+), 8 deletions(-)
--- 4.5-rc1/mm/gup.c2016-01-24 14:54:58.031544001 -0800
+++ linux/mm/gup.c 2016-01-30 17:14:21.443281994 -0800
@@ -430,10 +430,8 @@ static int check_vma_flags(struct vm_are
* Anon pages in shared mappings are surprising: now
* just reject it.
*/
- if (!is_cow_mapping(vm_flags)) {
- WARN_ON_ONCE(vm_flags & VM_MAYWRITE);
+ if (!is_cow_mapping(vm_flags))
return -EFAULT;
- }
}
} else if (!(vm_flags & VM_READ)) {
if (!(gup_flags & FOLL_FORCE))
--- 4.5-rc1/mm/memory.c 2016-01-24 14:54:58.051544131 -0800
+++ linux/mm/memory.c 2016-01-30 17:14:21.443281994 -0800
@@ -2232,11 +2232,6 @@ static int wp_page_shared(struct mm_stru
page_cache_get(old_page);
- /*
-* Only catch write-faults on shared writable pages,
-* read-only shared pages can get COWed by
-* get_user_pages(.write=1, .force=1).
-*/
if (vma->vm_ops && vma->vm_ops->page_mkwrite) {
int tmp;
Re: [PATCHv4 1/3] rdmacg: Added rdma cgroup controller.
Hi Parav,
[auto build test ERROR on cgroup/for-next]
[also build test ERROR on v4.5-rc1 next-20160129]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Parav-Pandit/rdmacg-IB-core-rdma-controller-support/20160131-063313
base: https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-next
config: i386-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
kernel/cgroup_rdma.c: In function 'find_cg_rpool_locked':
>> kernel/cgroup_rdma.c:179:84: error: invalid type argument of '->' (have
>> 'spinlock_t {aka struct spinlock}')
vim +179 kernel/cgroup_rdma.c
173 struct rdmacg_device *device,
174 enum rdmacg_resource_pool_type type)
175
176 {
177 struct cg_resource_pool *pool;
178
> 179 lockdep_assert_held(cg->rpool_list_lock);
180
181 list_for_each_entry(pool, >rpool_head, cg_list)
182 if (pool->device == device && pool->type == type)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[PATCH 02/14] clk: sunxi: Add apb0 gates for A83T
APB0 is part of PRCM, and is compatible with earlier SOCs. apb0 gates controls R_PIO, R_UART, R_RSB, etc clocks. This patch adds support for APB0 gates for A83T. Signed-off-by: Vishnu Patekar --- Documentation/devicetree/bindings/clock/sunxi.txt | 1 + drivers/clk/sunxi/clk-simple-gates.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt index e59f57b..7f19ef5 100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++ b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -39,6 +39,7 @@ Required properties: "allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31 "allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23 "allwinner,sun9i-a80-apb0-clk" - for the APB0 bus clock on A80 + "allwinner,sun8i-a83t-apb0-gates-clk" - for the APB0 gates on A83T "allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10 "allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13 "allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c index f4da52b..2cfc5a8 100644 --- a/drivers/clk/sunxi/clk-simple-gates.c +++ b/drivers/clk/sunxi/clk-simple-gates.c @@ -130,6 +130,8 @@ CLK_OF_DECLARE(sun8i_a23_apb2, "allwinner,sun8i-a23-apb2-gates-clk", sunxi_simple_gates_init); CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk", sunxi_simple_gates_init); +CLK_OF_DECLARE(sun8i_a83t_apb0, "allwinner,sun8i-a83t-apb0-gates-clk", + sunxi_simple_gates_init); CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk", sunxi_simple_gates_init); CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk", -- 1.9.1
[PATCH 09/14] ARM: dts: sun8i-a83t: Add mmc controller nodes
A83T mmc is compatible with earliers sunxi socs.
This adds mmc0, mmc1, and mmc2 controller nodes for A83T.
Signed-off-by: Vishnu Patekar
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 57 +++
1 file changed, 57 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index b8c8b60..ac96aa1 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -276,6 +276,63 @@
#size-cells = <1>;
ranges;
+ mmc0: mmc@01c0f000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <_gates 8>,
+<_clk 0>,
+<_clk 1>,
+<_clk 2>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <_reset0 8>;
+ reset-names = "ahb";
+ interrupts = ;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc1: mmc@01c1 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c1 0x1000>;
+ clocks = <_gates 9>,
+<_clk 0>,
+<_clk 1>,
+<_clk 2>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <_reset0 9>;
+ reset-names = "ahb";
+ interrupts = ;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc2: mmc@01c11000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c11000 0x1000>;
+ clocks = <_gates 10>,
+<_clk 0>,
+<_clk 1>,
+<_clk 2>;
+ clock-names = "ahb",
+ "mmc",
+ "output",
+ "sample";
+ resets = <_reset0 10>;
+ reset-names = "ahb";
+ interrupts = ;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
pio: pinctrl@01c20800 {
compatible = "allwinner,sun8i-a83t-pinctrl";
interrupts = ,
--
1.9.1
[PATCH 11/14] ARM: dts: sun8i-a83t: Add R_PIO controller node to the dtsi
Now that we have a driver for the R_PIO controller,
add the corresponding device node to the dtsi.
Signed-off-by: Vishnu Patekar
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 5ea20ff..11be9e1 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -478,5 +478,26 @@
compatible = "allwinner,sun6i-a31-clock-reset";
#reset-cells = <1>;
};
+
+ r_pio: pinctrl@01f02c00 {
+ compatible = "allwinner,sun8i-a83t-r-pinctrl";
+ reg = <0x01f02c00 0x400>;
+ interrupts = ;
+ clocks = <_gates 0>;
+ resets = <_reset 0>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #gpio-cells = <3>;
+
+ r_rsb_pins: r_rsb {
+ allwinner,pins = "PL0", "PL1";
+ allwinner,function = "s_rsb";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+ };
};
};
--
1.9.1
[PATCH 13/14] ARM: dts: sun8i: enable mmc for H8Homlet Board.
This enables mmc0.
Signed-off-by: Vishnu Patekar
Tested-by: LABBE Corentin
---
.../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts| 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
index 342e1d3..6c1f598 100644
--- a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
@@ -43,6 +43,7 @@
/dts-v1/;
#include "sun8i-a83t.dtsi"
+#include "sunxi-common-regulators.dtsi"
/ {
model = "Allwinner A83T H8Homlet Proto Dev Board v2.0";
@@ -57,6 +58,25 @@
};
};
+ {
+ mmc0_cd_pin_h8homlet: mmc0_cd_pin@0 {
+ allwinner,pins = "PF6";
+ allwinner,function = "gpio_in";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>, <_cd_pin_h8homlet>;
+ vmmc-supply = <_vcc3v0>;
+ cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ bus-width = <4>;
+ cd-inverted;
+ status = "okay";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins_b>;
--
1.9.1
[PATCH 14/14] ARM: dts: sun8i: Add A83T based Sinovoip Bpi-M3 Board
This patch adds support for Sinovoip BPI-M3 A83T based board.
It has 2G LPDDR3, UART, ethernet, USB, HDMI, USB Sata, MIPI DSI,
mic, AP6212 Wifi, etc on it.
It is paired with AXP813 PMIC which is almost same as AXP818.
Signed-off-by: Vishnu Patekar
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts | 88
2 files changed, 89 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 58e461a..c0dd016 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -694,6 +694,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-sinlinx-sina33.dtb \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
+ sun8i-a83t-sinovoip-bpi-m3.dtb \
sun8i-h3-orangepi-plus.dtb
dtb-$(CONFIG_MACH_SUN9I) += \
sun9i-a80-optimus.dtb \
diff --git a/arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
b/arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
new file mode 100644
index 000..fecc7dc
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
@@ -0,0 +1,88 @@
+/*
+ * Copyright 2015 Vishnu Patekar
+ * Vishnu Patekar
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a83t.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+/ {
+ model = "Sinovoip BananaPi M3 v1.2";
+ compatible = "sinovoip,bpi-m3", "allwinner,sun8i-a83t";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ mmc0_cd_pin_bpi_m3: mmc0_cd_pin@0 {
+ allwinner,pins = "PF6";
+ allwinner,function = "gpio_in";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>, <_cd_pin_bpi_m3>;
+ vmmc-supply = <_vcc3v0>;
+ cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ bus-width = <4>;
+ cd-inverted;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_b>;
+ status = "okay";
+};
+
+_rsb {
+ status = "okay";
+};
--
1.9.1
[PATCH 08/14] ARM: dts: sun8i-a83t: add mmc clock nodes
mmc clocks are compatible with that of earlier sun8i socs.
This adds mmc0, mmc1, and mmc2 clock nodes for A83T.
Signed-off-by: Vishnu Patekar
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 568d6fb..b8c8b60 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -238,6 +238,36 @@
"bus_uart2", "bus_uart3",
"bus_uart4";
};
+
+ mmc0_clk: clk@01c20088 {
+ #clock-cells = <1>;
+ compatible = "allwinner,sun4i-a10-mmc-clk";
+ reg = <0x01c20088 0x4>;
+ clocks = <>, <>;
+ clock-output-names = "mmc0",
+"mmc0_output",
+"mmc0_sample";
+ };
+
+ mmc1_clk: clk@01c2008c {
+ #clock-cells = <1>;
+ compatible = "allwinner,sun4i-a10-mmc-clk";
+ reg = <0x01c2008c 0x4>;
+ clocks = <>, <>;
+ clock-output-names = "mmc1",
+"mmc1_output",
+"mmc1_sample";
+ };
+
+ mmc2_clk: clk@01c20090 {
+ #clock-cells = <1>;
+ compatible = "allwinner,sun4i-a10-mmc-clk";
+ reg = <0x01c20090 0x4>;
+ clocks = <>, <>;
+ clock-output-names = "mmc2",
+"mmc2_output",
+"mmc2_sample";
+ };
};
soc {
--
1.9.1
[PATCH 04/14] clk: sunxi: add ahb1 clock for A83T
AHB1 on A83T is similar to ahb1 on A31, except parents are different.
clock index 0b1x is PLL6.
Signed-off-by: Vishnu Patekar
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/clk-sunxi.c | 75 +++
2 files changed, 76 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 4514d77..bfd82f1 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -29,6 +29,7 @@ Required properties:
"allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
"allwinner,sun9i-a80-cpus-clk" - for the CPUS on A80
"allwinner,sun6i-a31-ahb1-clk" - for the AHB1 clock on A31
+ "allwinner,sun8i-a83t-ahb1-clk" - for the AHB1 clock on A83T
"allwinner,sun8i-h3-ahb2-clk" - for the AHB2 clock on H3
"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index e460a6b..02bbdf6 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -344,6 +344,67 @@ static void sun6i_ahb1_recalc(struct factors_request *req)
req->rate >>= req->p;
}
+
+#define SUN8I_A83T_AHB1_PARENT_PLL62
+/**
+ * sun8i_a83t_get_ahb_factors() - calculates m, p factors for AHB
+ * AHB rate is calculated as follows
+ * rate = parent_rate >> p
+ *
+ * if parent is pll6, then
+ * parent_rate = pll6 rate / (m + 1)
+ */
+
+static void sun8i_a83t_get_ahb1_factors(struct factors_request *req)
+{
+ u8 div, calcp, calcm = 1;
+
+ /*
+* clock can only divide, so we will never be able to achieve
+* frequencies higher than the parent frequency
+*/
+ if (req->parent_rate && req->rate > req->parent_rate)
+ req->rate = req->parent_rate;
+
+ div = DIV_ROUND_UP(req->parent_rate, req->rate);
+
+ /* calculate pre-divider if parent is pll6 */
+ if (req->parent_index >= SUN8I_A83T_AHB1_PARENT_PLL6) {
+ if (div < 4)
+ calcp = 0;
+ else if (div / 2 < 4)
+ calcp = 1;
+ else if (div / 4 < 4)
+ calcp = 2;
+ else
+ calcp = 3;
+
+ calcm = DIV_ROUND_UP(div, 1 << calcp);
+ } else {
+ calcp = __roundup_pow_of_two(div);
+ calcp = calcp > 3 ? 3 : calcp;
+ }
+
+ req->rate = (req->parent_rate / calcm) >> calcp;
+ req->p = calcp;
+ req->m = calcm - 1;
+}
+
+/**
+ * sun8i_a83t_ahb1_recalc() - calculates AHB clock rate from m, p factors and
+ * parent index
+ */
+static void sun8i_a83t_ahb1_recalc(struct factors_request *req)
+{
+ req->rate = req->parent_rate;
+
+ /* apply pre-divider first if parent is pll6 */
+ if (req->parent_index >= SUN6I_AHB1_PARENT_PLL6)
+ req->rate /= req->m + 1;
+
+ /* clk divider */
+ req->rate >>= req->p;
+}
/**
* sun4i_get_apb1_factors() - calculates m, p factors for APB1
* APB1 rate is calculated as follows
@@ -555,6 +616,14 @@ static const struct factors_data sun6i_ahb1_data
__initconst = {
.recalc = sun6i_ahb1_recalc,
};
+static const struct factors_data sun8i_a83t_ahb1_data __initconst = {
+ .mux = 12,
+ .muxmask = BIT(1) | BIT(0),
+ .table = _ahb1_config,
+ .getter = sun8i_a83t_get_ahb1_factors,
+ .recalc = sun8i_a83t_ahb1_recalc,
+};
+
static const struct factors_data sun4i_apb1_data __initconst = {
.mux = 24,
.muxmask = BIT(1) | BIT(0),
@@ -592,6 +661,12 @@ static void __init sun6i_ahb1_clk_setup(struct device_node
*node)
CLK_OF_DECLARE(sun6i_a31_ahb1, "allwinner,sun6i-a31-ahb1-clk",
sun6i_ahb1_clk_setup);
+static void __init sun8i_a83t_ahb1_clk_setup(struct device_node *node)
+{
+ sunxi_factors_clk_setup(node, _a83t_ahb1_data);
+}
+CLK_OF_DECLARE(sun8i_a83t_ahb1, "allwinner,sun8i-a83t-ahb1-clk",
+ sun8i_a83t_ahb1_clk_setup);
/**
* sunxi_mux_clk_setup() - Setup function for muxes
--
1.9.1
[PATCH 06/14] ARM: dts: sun8i-a83t: Correct low speed oscillator clocks
From: Chen-Yu Tsai
The A83T does not have a 32.768 kHz low speed oscillator, either as
an external crystal or input. It has a 16 MHz RC-based (inaccurate)
internal oscillator, which is then divided by 512 for a clock close
to 32 kHz.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 8d27b63..45b725c 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -118,6 +118,7 @@
#size-cells = <1>;
ranges;
+ /* TODO: PRCM block has a mux for this. */
osc24M: osc24M_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
@@ -125,11 +126,25 @@
clock-output-names = "osc24M";
};
- osc32k: osc32k_clk {
+ /*
+* This is called "internal OSC" in some places.
+* It is an internal RC-based oscillator.
+* TODO: Its controls are in the PRCM block.
+*/
+ osc16M: osc16M_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
- clock-frequency = <32768>;
- clock-output-names = "osc32k";
+ clock-frequency = <1600>;
+ clock-output-names = "osc16M";
+ };
+
+ osc16Md512: osc16Md512_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clock-div = <512>;
+ clock-mult = <1>;
+ clocks = <>;
+ clock-output-names = "osc16Md512";
};
};
--
1.9.1
[PATCH 03/14] clk: sunxi: add bus gates for A83T
A83T has similar bus gates that of H3, including single gating register has different clock parent. As per H3 and A83T datasheet, usbhost is under AHB2. However,below shows allwinner source code assignment: bits: 26 (ehci0), 27 (ehci1), 29 (ohci0) => AHB1 for A83T. bits: 26 (ehci0), 27 (ehci1) => AHB1 for H3 bits 29, 30, 31(ohci0,1,2) => AHB2 for H3. until, this confusion is cleared keep it H3 way. Signed-off-by: Vishnu Patekar --- Documentation/devicetree/bindings/clock/sunxi.txt | 1 + drivers/clk/sunxi/clk-sun8i-bus-gates.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt index 7f19ef5..4514d77 100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++ b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -59,6 +59,7 @@ Required properties: "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31 "allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23 "allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3 + "allwinner,sun8i-a83t-bus-gates-clk" - for the bus gates on A83T "allwinner,sun9i-a80-apbs-gates-clk" - for the APBS gates on A80 "allwinner,sun4i-a10-dram-gates-clk" - for the DRAM gates on A10 "allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13 diff --git a/drivers/clk/sunxi/clk-sun8i-bus-gates.c b/drivers/clk/sunxi/clk-sun8i-bus-gates.c index 1113eb9..63fdb79 100644 --- a/drivers/clk/sunxi/clk-sun8i-bus-gates.c +++ b/drivers/clk/sunxi/clk-sun8i-bus-gates.c @@ -109,3 +109,5 @@ err_unmap: CLK_OF_DECLARE(sun8i_h3_bus_gates, "allwinner,sun8i-h3-bus-gates-clk", sun8i_h3_bus_gates_init); +CLK_OF_DECLARE(sun8i_a83t_bus_gates, "allwinner,sun8i-a83t-bus-gates-clk", + sun8i_h3_bus_gates_init); -- 1.9.1
[PATCH 05/14] clk: sunxi: Add APB1 clock for A83T
APB1 is similar to sun4i-a10-apb0-clk, except different dividers.
This adds support for apb1 on A83T.
Signed-off-by: Vishnu Patekar
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/clk-sunxi.c | 17 +
2 files changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index bfd82f1..10637e7 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -49,6 +49,7 @@ Required properties:
"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
+ "allwinner,sun8i-a83t-apb1-clk" - for the APB1 clock on A83T
"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
"allwinner,sun4i-a10-apb1-gates-clk" - for the APB1 gates on A10
"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 02bbdf6..6510b0e 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -772,6 +772,22 @@ static const struct div_data sun4i_apb0_data __initconst =
{
.table = sun4i_apb0_table,
};
+
+static const struct clk_div_table sun8i_a83t_apb1_table[] __initconst = {
+ { .val = 0, .div = 1 },
+ { .val = 1, .div = 2 },
+ { .val = 2, .div = 3 },
+ { .val = 3, .div = 4 },
+ { } /* sentinel */
+};
+
+static const struct div_data sun8i_a83t_apb1_data __initconst = {
+ .shift = 8,
+ .pow= 0,
+ .width = 2,
+ .table = sun8i_a83t_apb1_table,
+};
+
static void __init sunxi_divider_clk_setup(struct device_node *node,
struct div_data *data)
{
@@ -1027,6 +1043,7 @@ static const struct of_device_id clk_div_match[]
__initconst = {
{.compatible = "allwinner,sun8i-a23-axi-clk", .data =
_a23_axi_data,},
{.compatible = "allwinner,sun4i-a10-ahb-clk", .data = _ahb_data,},
{.compatible = "allwinner,sun4i-a10-apb0-clk", .data =
_apb0_data,},
+ {.compatible = "allwinner,sun8i-a83t-apb1-clk", .data =
_a83t_apb1_data,},
{}
};
--
1.9.1
[PATCH 10/14] ARM: dts: sun8i-a83t: Add PRCM related clocks and resets
This adds A83T PRCM related clocks, clock resets.
As a83t apb0 gates clock support is added earlier, this enables it.
Apart from apb0 gates, other added clocks are compatible with
earlier sun8i socs.
Signed-off-by: Vishnu Patekar
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 44 +++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index ac96aa1..5ea20ff 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -268,6 +268,44 @@
"mmc2_output",
"mmc2_sample";
};
+
+ cpus_clk: clk@01f01400 {
+ compatible = "allwinner,sun9i-a80-cpus-clk";
+ reg = <0x01f01400 0x4>;
+ #clock-cells = <0>;
+ clocks = <>, <>, <>, <>;
+ clock-output-names = "cpus";
+ };
+
+ ahb0: ahb0_clk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <1>;
+ clock-mult = <1>;
+ clocks = <_clk>;
+ clock-output-names = "ahb0";
+ };
+
+ apb0: clk@01f0140c {
+ compatible = "allwinner,sun8i-a23-apb0-clk";
+ reg = <0x01f0140c 0x4>;
+ #clock-cells = <0>;
+ clocks = <>;
+ clock-output-names = "apb0";
+ };
+
+ apb0_gates: clk@01f01428 {
+ compatible = "allwinner,sun8i-a83t-apb0-gates-clk";
+ reg = <0x01f01428 0x4>;
+ #clock-cells = <1>;
+ clocks = <>;
+ clock-indices = <0>, <1>,
+ <2>, <3>,
+ <4>, <6>, <7>;
+ clock-output-names = "apb0_pio", "apb0_ir",
+ "apb0_timer", "apb0_rsb",
+ "apb0_uart", "apb0_i2c0", "apb0_twd";
+ };
};
soc {
@@ -434,5 +472,11 @@
#interrupt-cells = <3>;
interrupts = ;
};
+
+ apb0_reset: reset@01f014b0 {
+ reg = <0x01f014b0 0x4>;
+ compatible = "allwinner,sun6i-a31-clock-reset";
+ #reset-cells = <1>;
+ };
};
};
--
1.9.1
[PATCH 07/14] ARM: dts: sun8i-a83t: Add basic clocks and resets
This adds A83T system bus clocks, bus gates, and clock resets.
For ahb1 and ahb2, it's not clear which reset belongs to ahb1
or ahb2; so named as ahb_reset0, ahb_reset1, ahb_reset2.
Signed-off-by: Vishnu Patekar
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 127 +-
1 file changed, 125 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 45b725c..568d6fb 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -146,6 +146,98 @@
clocks = <>;
clock-output-names = "osc16Md512";
};
+
+
+ pll6: clk@01c20028 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun9i-a80-pll4-clk";
+ reg = <0x01c20028 0x4>;
+ clocks = <>;
+ clock-output-names = "pll6";
+ };
+
+ pll6d2: pll6d2_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clock-div = <2>;
+ clock-mult = <1>;
+ clocks = <>;
+ clock-output-names = "pll6d2";
+ };
+
+ ahb1: ahb1_clk@01c20054 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun8i-a83t-ahb1-clk";
+ reg = <0x01c20054 0x4>;
+ clocks = <>, <>, <>, <>;
+ clock-output-names = "ahb1";
+ };
+
+ ahb2: ahb2_clk@01c2005c {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun8i-h3-ahb2-clk";
+ reg = <0x01c2005c 0x4>;
+ clocks = <>, <>;
+ clock-output-names = "ahb2";
+ };
+
+ apb1: apb1_clk@01c20054 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun8i-a83t-apb1-clk";
+ reg = <0x01c20054 0x4>;
+ clocks = <>;
+ clock-output-names = "apb1";
+ };
+
+ apb2: clk@01c20058 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun4i-a10-apb1-clk";
+ reg = <0x01c20058 0x4>;
+ clocks = <>, <>, <>, <>;
+ clock-output-names = "apb2";
+ };
+
+ bus_gates: clk@01c20060 {
+ #clock-cells = <1>;
+ compatible = "allwinner,sun8i-a83t-bus-gates-clk";
+ reg = <0x01c20060 0x10>;
+ clocks = <>, <>, <>, <>;
+ clock-names = "ahb1", "ahb2", "apb1", "apb2";
+ clock-indices = <1>, <5>, <6>,
+ <8>, <9>, <10>,
+ <13>, <14>, <17>,
+ <19>, <20>,
+ <21>, <24>,
+ <26>, <27>,
+ <29>, <32>,
+ <36>, <37>,
+ <40>, <43>,
+ <44>, <52>, <53>,
+ <54>, <65>,
+ <69>, <76>, <77>,
+ <78>, <79>, <96>,
+ <97>, <98>,
+ <112>, <113>,
+ <114>, <115>,
+ <116>;
+ clock-output-names = "bus_mipidsi", "bus_ss", "bus_dma",
+"bus_mmc0", "bus_mmc1", "bus_mmc2",
+"bus_nand", "bus_sdram",
"bus_emac",
+"bus_hstimer", "bus_spi0",
+"bus_spi1", "bus_usb_drd",
+"bus_ehci0", "bus_ehci1",
+"bus_ohci0", "bus_ve",
+"bus_lcd0", "bus_lcd1",
+"bus_csi", "bus_hdmi",
+"bus_de", "bus_gpu", "bus_msgbox",
+"bus_spinlock", "bus_owa",
+"bus_pio", "bus_i2s0", "bus_i2s1",
+"bus_i2s2", "bus_tdm", "bus_i2c0",
+"bus_i2c1", "bus_i2c2",
+"bus_uart0", "bus_uart1",
+
[PATCH 12/14] ARM: dts: sun8i-a83t: Add RSB nodes to dtsi
This adds support for RSB
A83T RSB is compatible with A23 rsb.
Signed-off-by: Vishnu Patekar
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 11be9e1..8c67c85 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -499,5 +499,19 @@
allwinner,pull = ;
};
};
+
+ r_rsb: i2c@01f03400 {
+ compatible = "allwinner,sun8i-a23-rsb";
+ reg = <0x01f03400 0x400>;
+ interrupts = ;
+ clocks = <_gates 3>;
+ clock-frequency = <300>;
+ resets = <_reset 3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_rsb_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
};
--
1.9.1
[PATCH 3/5] HSI: ssi-protocol: export modem info via sysfs
Currently userspace knows about the rapuyama version by
checking, which gpios have been exported. This does no
longer work with kernel based power management, so export
a sysfs file, which provides the rapuyama generation. Also
export a link to the nokia-modem, so that userspace can
easily check if kernel based PM is used.
Signed-off-by: Sebastian Reichel
---
drivers/hsi/clients/nokia-modem.c | 10 --
drivers/hsi/clients/ssi_protocol.c | 33 -
include/linux/hsi/ssi_protocol.h | 11 +++
3 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/drivers/hsi/clients/nokia-modem.c
b/drivers/hsi/clients/nokia-modem.c
index 6485f4c61092..1b4a250cf113 100644
--- a/drivers/hsi/clients/nokia-modem.c
+++ b/drivers/hsi/clients/nokia-modem.c
@@ -35,11 +35,6 @@ module_param(pm, int, 0400);
MODULE_PARM_DESC(pm,
"Enable power management (0=disabled, 1=userland based [default],
2=kernel based)");
-enum nokia_modem_type {
- RAPUYAMA_V1,
- RAPUYAMA_V2,
-};
-
struct nokia_modem_device {
struct tasklet_struct nokia_modem_rst_ind_tasklet;
int nokia_modem_rst_ind_irq;
@@ -285,6 +280,7 @@ static int nokia_modem_probe(struct device *dev)
struct hsi_port *port = hsi_get_port(cl);
int irq, pflags, err;
struct hsi_board_info ssip;
+ struct ssi_protocol_platform_data ssip_pdata;
struct hsi_board_info cmtspeech;
np = dev->of_node;
@@ -340,7 +336,9 @@ static int nokia_modem_probe(struct device *dev)
ssip.name = "ssi-protocol";
ssip.tx_cfg = cl->tx_cfg;
ssip.rx_cfg = cl->rx_cfg;
- ssip.platform_data = NULL;
+ ssip_pdata.type = modem->type;
+ ssip_pdata.nokia_modem_dev = dev;
+ ssip.platform_data = _pdata;
ssip.archdata = NULL;
modem->ssi_protocol = hsi_new_client(port, );
diff --git a/drivers/hsi/clients/ssi_protocol.c
b/drivers/hsi/clients/ssi_protocol.c
index cee33cab889e..3fb5b98b2c63 100644
--- a/drivers/hsi/clients/ssi_protocol.c
+++ b/drivers/hsi/clients/ssi_protocol.c
@@ -154,6 +154,7 @@ struct ssi_protocol {
int channel_id_cmd;
int channel_id_data;
struct blocking_notifier_head modem_state_notifier;
+ enum nokia_modem_type modem_type;
};
/* List of ssi protocol instances */
@@ -1080,10 +1081,20 @@ static void ssip_pn_setup(struct net_device *dev)
dev->header_ops = _header_ops;
}
+static ssize_t show_rapuyama_version(struct device *dev, struct
device_attribute *attr, char *buf)
+{
+ struct hsi_client *cl = to_hsi_client(dev);
+ struct ssi_protocol *ssi = hsi_client_drvdata(cl);
+
+ return sprintf(buf, "%d", ssi->modem_type);
+}
+static DEVICE_ATTR(rapuyama_version, S_IRUGO, show_rapuyama_version, 0);
+
static int ssi_protocol_probe(struct device *dev)
{
static const char ifname[] = "phonet%d";
struct hsi_client *cl = to_hsi_client(dev);
+ struct ssi_protocol_platform_data *pdata = dev_get_platdata(dev);
struct ssi_protocol *ssi;
int err;
@@ -1093,6 +1104,8 @@ static int ssi_protocol_probe(struct device *dev)
return -ENOMEM;
}
+ ssi->modem_type = pdata->type;
+
spin_lock_init(>lock);
init_timer_deferrable(>rx_wd);
init_timer_deferrable(>tx_wd);
@@ -1137,12 +1150,24 @@ static int ssi_protocol_probe(struct device *dev)
goto out1;
}
+ err = device_create_file(dev, _attr_rapuyama_version);
+ if (err < 0) {
+ dev_err(dev, "Could not create sysfs file for rapuyama
version");
+ goto out2;
+ }
+
+ err = sysfs_create_link(>kobj, >nokia_modem_dev->kobj,
"nokia-modem");
+ if (err < 0) {
+ dev_err(dev, "Could not create sysfs symlink to nokia-modem");
+ goto out3;
+ }
+
SET_NETDEV_DEV(ssi->netdev, dev);
netif_carrier_off(ssi->netdev);
err = register_netdev(ssi->netdev);
if (err < 0) {
dev_err(dev, "Register netdev failed (%d)\n", err);
- goto out2;
+ goto out4;
}
list_add(>link, _list);
@@ -1151,6 +1176,10 @@ static int ssi_protocol_probe(struct device *dev)
ssi->channel_id_cmd, ssi->channel_id_data);
return 0;
+out4:
+ sysfs_remove_link(>kobj, "nokia-modem");
+out3:
+ device_remove_file(dev, _attr_rapuyama_version);
out2:
free_netdev(ssi->netdev);
out1:
@@ -1167,6 +1196,8 @@ static int ssi_protocol_remove(struct device *dev)
struct ssi_protocol *ssi = hsi_client_drvdata(cl);
list_del(>link);
+ sysfs_remove_link(>kobj, "nokia-modem");
+ device_remove_file(dev, _attr_rapuyama_version);
unregister_netdev(ssi->netdev);
ssip_free_cmds(ssi);
hsi_client_set_drvdata(cl, NULL);
diff --git
[PATCH 00/14] Add A83T clk, r_pio, mmc rsb support
Hello,
This series adds further support for A83T, mainly adds clock support.
Also adds R_PIO, PRCM related clocks, mmc, rsb support.
A83T difference in short:
R_PIO is slightly different from A23 r_pio. AHB1 has different parents as
compared to a31-ahb1, APB1 has different dividers.Bus gates are similar to H3,
apb0 gates are different.mmc and rsb are compatible with earlier sunxi socs.
Patch 1: adds support for r_pio pin controller.
patch 2: adds PRCM apb0 clock gates, it controls prcm related clocks.
patch 3: adds bus gates which are similar to h3, it's not clearly known which
clocks belongs to which parent.
patch 4: adds ahb1 clock support, 0b1x is pll6 parent otherwise it's same as a31
ahb1.
patch 5: adds apb1 clock support, apb1 has different dividers compared to a10
apb0 clock.
patch 6: this patch is form wens, a83t has 16M internal oscillator, to get
aproximately 32k clock, it's divided by 512.
patch 7: adds basics clocks nodes to dtsi, pll6, ahb1, ahb2, apb1, apb2,
bus gates, and resets.
patch 8-9: adds mmc and it's clock nodes.
patch 10: adds A83T PRCM related clocks, clock resets.
patch 11: adds r_pio pin controller nodes to dtsi
patch 12: adds RSB nodes to dtsi
patch 13: enables mmc0 support for h8homlet board, tested by LABBE Corentin.
patch 14: This patch adds support for Sinovoip BPI-M3 A83T based board, it has
2GB LPDDR3, u-boot support is added recently for this board.
Regards,
Vishnu
Chen-Yu Tsai (1):
ARM: dts: sun8i-a83t: Correct low speed oscillator clocks
Vishnu Patekar (13):
pinctrl: sunxi: Add A83T R_PIO controller support
clk: sunxi: Add apb0 gates for A83T
clk: sunxi: add bus gates for A83T
clk: sunxi: add ahb1 clock for A83T
clk: sunxi: Add APB1 clock for A83T
ARM: dts: sun8i-a83t: Add basic clocks and resets
ARM: dts: sun8i-a83t: add mmc clock nodes
ARM: dts: sun8i-a83t: Add mmc controller nodes
ARM: dts: sun8i-a83t: Add PRCM related clocks and resets
ARM: dts: sun8i-a83t: Add R_PIO controller node to the dtsi
ARM: dts: sun8i-a83t: Add RSB nodes to dtsi
ARM: dts: sun8i: enable mmc for H8Homlet Board.
ARM: dts: sun8i: Add A83T based Sinovoip Bpi-M3 Board
Documentation/devicetree/bindings/clock/sunxi.txt | 4 +
.../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
.../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 20 ++
...omlet-v2.dts => sun8i-a83t-sinovoip-bpi-m3.dts} | 28 +-
arch/arm/boot/dts/sun8i-a83t.dtsi | 314 -
drivers/clk/sunxi/clk-simple-gates.c | 2 +
drivers/clk/sunxi/clk-sun8i-bus-gates.c| 2 +
drivers/clk/sunxi/clk-sunxi.c | 92 ++
drivers/pinctrl/sunxi/Kconfig | 5 +
drivers/pinctrl/sunxi/Makefile | 1 +
drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c | 119
12 files changed, 582 insertions(+), 7 deletions(-)
copy arch/arm/boot/dts/{sun8i-a83t-allwinner-h8homlet-v2.dts =>
sun8i-a83t-sinovoip-bpi-m3.dts} (79%)
create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c
--
1.9.1
[PATCH 01/14] pinctrl: sunxi: Add A83T R_PIO controller support
The A83T has R_PIO pin controller, it's same as A23, execpt A83T
interrupt bit is 6th and A83T has one extra pin PL12.
Signed-off-by: Vishnu Patekar
---
.../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
drivers/pinctrl/sunxi/Kconfig | 5 +
drivers/pinctrl/sunxi/Makefile | 1 +
drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c | 119 +
4 files changed, 126 insertions(+)
create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c
diff --git
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 9213b27..f9ff10b 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -20,6 +20,7 @@ Required properties:
"allwinner,sun9i-a80-pinctrl"
"allwinner,sun9i-a80-r-pinctrl"
"allwinner,sun8i-a83t-pinctrl"
+ "allwinner,sun8i-a83t-r-pinctrl"
"allwinner,sun8i-h3-pinctrl"
- reg: Should contain the register physical address and length for the
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index f8dbc8b..c0e4a8b 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -46,6 +46,11 @@ config PINCTRL_SUN8I_A83T
def_bool MACH_SUN8I
select PINCTRL_SUNXI_COMMON
+config PINCTRL_SUN8I_A83T_R
+ def_bool MACH_SUN8I
+ depends on RESET_CONTROLLER
+ select PINCTRL_SUNXI_COMMON
+
config PINCTRL_SUN8I_A23_R
def_bool MACH_SUN8I
depends on RESET_CONTROLLER
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index ef82f22..bfd4fa0 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23) +=
pinctrl-sun8i-a23.o
obj-$(CONFIG_PINCTRL_SUN8I_A23_R) += pinctrl-sun8i-a23-r.o
obj-$(CONFIG_PINCTRL_SUN8I_A33)+= pinctrl-sun8i-a33.o
obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o
+obj-$(CONFIG_PINCTRL_SUN8I_A83T_R) += pinctrl-sun8i-a83t-r.o
obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
obj-$(CONFIG_PINCTRL_SUN9I_A80)+= pinctrl-sun9i-a80.o
obj-$(CONFIG_PINCTRL_SUN9I_A80_R) += pinctrl-sun9i-a80-r.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c
b/drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c
new file mode 100644
index 000..11787894
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c
@@ -0,0 +1,119 @@
+/*
+ * Allwinner A83T SoCs special pins pinctrl driver.
+ *
+ * Copyright (C) 2016 Vishnu Patekar
+ * Vishnu Patekar
+ *
+ * Based on pinctrl-sun8i-a23.c, which is:
+ * Copyright (C) 2014 Chen-Yu Tsai
+ * Copyright (C) 2014 Maxime Ripard
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun8i_a83t_r_pins[] = {
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_rsb"), /* SCK */
+ SUNXI_FUNCTION(0x3, "s_twi"), /* SCK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PL_EINT0 */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_rsb"), /* SDA */
+ SUNXI_FUNCTION(0x3, "s_twi"), /* SDA */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /* PL_EINT1 */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_uart"),/* TX */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)), /* PL_EINT2 */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_uart"),/* RX */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)), /* PL_EINT3 */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_jtag"),/* MS */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)), /* PL_EINT4 */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_jtag"),/* CK */
+
[PATCH 1/5] HSI: nokia-modem: simplify kernel access to gpios
For implementing kernel based modem power management, the
gpios should be accessible via name from the kernel. The
old code would require walking through the gpio array
comparing the name of each gpio. This is no longer needed
by the new code, which does the comparing once at probe
time. As a side effect the code now checks, that all
required gpios are provided.
Signed-off-by: Sebastian Reichel
---
drivers/hsi/clients/nokia-modem.c | 115 --
1 file changed, 85 insertions(+), 30 deletions(-)
diff --git a/drivers/hsi/clients/nokia-modem.c
b/drivers/hsi/clients/nokia-modem.c
index c000780d931f..f20ede611593 100644
--- a/drivers/hsi/clients/nokia-modem.c
+++ b/drivers/hsi/clients/nokia-modem.c
@@ -34,19 +34,23 @@ module_param(pm, int, 0400);
MODULE_PARM_DESC(pm,
"Enable power management (0=disabled, 1=userland based [default])");
-struct nokia_modem_gpio {
- struct gpio_desc*gpio;
- const char *name;
+enum nokia_modem_type {
+ RAPUYAMA_V1,
+ RAPUYAMA_V2,
};
struct nokia_modem_device {
struct tasklet_struct nokia_modem_rst_ind_tasklet;
int nokia_modem_rst_ind_irq;
struct device *device;
- struct nokia_modem_gpio *gpios;
- int gpio_amount;
struct hsi_client *ssi_protocol;
struct hsi_client *cmt_speech;
+ enum nokia_modem_type type;
+ struct gpio_desc*gpio_cmt_en;
+ struct gpio_desc*gpio_cmt_apeslpx;
+ struct gpio_desc*gpio_cmt_rst_rq;
+ struct gpio_desc*gpio_cmt_rst;
+ struct gpio_desc*gpio_cmt_bsi;
};
static void do_nokia_modem_rst_ind_tasklet(unsigned long data)
@@ -74,11 +78,33 @@ static irqreturn_t nokia_modem_rst_ind_isr(int irq, void
*data)
static void nokia_modem_gpio_unexport(struct device *dev)
{
struct nokia_modem_device *modem = dev_get_drvdata(dev);
- int i;
- for (i = 0; i < modem->gpio_amount; i++) {
- sysfs_remove_link(>kobj, modem->gpios[i].name);
- gpiod_unexport(modem->gpios[i].gpio);
+ if (pm != 1)
+ return;
+
+ if (modem->gpio_cmt_en) {
+ sysfs_remove_link(>kobj, "cmt_en");
+ gpiod_unexport(modem->gpio_cmt_en);
+ }
+
+ if (modem->gpio_cmt_apeslpx) {
+ sysfs_remove_link(>kobj, "cmt_apeslpx");
+ gpiod_unexport(modem->gpio_cmt_apeslpx);
+ }
+
+ if (modem->gpio_cmt_rst_rq) {
+ sysfs_remove_link(>kobj, "cmt_rst_rq");
+ gpiod_unexport(modem->gpio_cmt_rst_rq);
+ }
+
+ if (modem->gpio_cmt_rst) {
+ sysfs_remove_link(>kobj, "cmt_rst");
+ gpiod_unexport(modem->gpio_cmt_rst);
+ }
+
+ if (modem->gpio_cmt_bsi) {
+ sysfs_remove_link(>kobj, "cmt_bsi");
+ gpiod_unexport(modem->gpio_cmt_bsi);
}
}
@@ -102,38 +128,61 @@ static int nokia_modem_gpio_probe(struct device *dev)
return -EINVAL;
}
- modem->gpios = devm_kzalloc(dev, gpio_count *
- sizeof(struct nokia_modem_gpio), GFP_KERNEL);
- if (!modem->gpios) {
- dev_err(dev, "Could not allocate memory for gpios\n");
- return -ENOMEM;
- }
-
- modem->gpio_amount = gpio_count;
-
for (i = 0; i < gpio_count; i++) {
- modem->gpios[i].gpio = devm_gpiod_get_index(dev, NULL, i,
- GPIOD_OUT_LOW);
- if (IS_ERR(modem->gpios[i].gpio)) {
+ const char *gpio_name;
+ struct gpio_desc *gpio_val;
+
+ gpio_val = devm_gpiod_get_index(dev, NULL, i, GPIOD_OUT_LOW);
+ if (IS_ERR(gpio_val)) {
dev_err(dev, "Could not get gpio %d\n", i);
- return PTR_ERR(modem->gpios[i].gpio);
+ return PTR_ERR(gpio_val);
}
err = of_property_read_string_index(np, "gpio-names", i,
- &(modem->gpios[i].name));
+ _name);
if (err) {
dev_err(dev, "Could not get gpio name %d\n", i);
return err;
}
- err = gpiod_export(modem->gpios[i].gpio, 0);
- if (err)
- return err;
+ if (strcmp(gpio_name, "cmt_en") == 0) {
+ modem->gpio_cmt_en = gpio_val;
+ } else if(strcmp(gpio_name, "cmt_apeslpx") == 0) {
+ modem->gpio_cmt_apeslpx = gpio_val;
+ } else if(strcmp(gpio_name, "cmt_rst_rq") == 0) {
+ modem->gpio_cmt_rst_rq = gpio_val;
+ } else if(strcmp(gpio_name,
[PATCH 5/5] HSI: ssi-protocol: clear carrier flag on open
If the interface is just being enabled, the modem is not
yet ready to be used, so clear the carrier flag (which is
e.g. set by ifconfig and ofono).
Signed-off-by: Sebastian Reichel
---
drivers/hsi/clients/ssi_protocol.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hsi/clients/ssi_protocol.c
b/drivers/hsi/clients/ssi_protocol.c
index 3fb5b98b2c63..264f81cfa095 100644
--- a/drivers/hsi/clients/ssi_protocol.c
+++ b/drivers/hsi/clients/ssi_protocol.c
@@ -916,6 +916,8 @@ static int ssip_pn_open(struct net_device *dev)
struct ssi_protocol *ssi = hsi_client_drvdata(cl);
int err;
+ netif_carrier_off(ssi->netdev);
+
err = hsi_claim_port(cl, 1);
if (err < 0) {
dev_err(>device, "SSI port already claimed\n");
--
2.7.0.rc3
[PATCH 4/5] HSI: nokia-modem: drop support for disabled pm
Disabled power management means, that the driver can only be
used together with further out-of-tree kernel patches. There
is no reason to support this in the mainline kernel and not
having support for it means, that userspace can automatically
detect if we are running kernel based power management.
Signed-off-by: Sebastian Reichel
---
drivers/hsi/clients/nokia-modem.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/hsi/clients/nokia-modem.c
b/drivers/hsi/clients/nokia-modem.c
index 1b4a250cf113..5e333eb82912 100644
--- a/drivers/hsi/clients/nokia-modem.c
+++ b/drivers/hsi/clients/nokia-modem.c
@@ -33,7 +33,7 @@
static unsigned int pm = 1;
module_param(pm, int, 0400);
MODULE_PARM_DESC(pm,
- "Enable power management (0=disabled, 1=userland based [default],
2=kernel based)");
+ "Enable power management (1=userland based [default], 2=kernel based)");
struct nokia_modem_device {
struct tasklet_struct nokia_modem_rst_ind_tasklet;
@@ -198,6 +198,11 @@ static int nokia_modem_gpio_probe(struct device *dev)
struct nokia_modem_device *modem = dev_get_drvdata(dev);
int gpio_count, gpio_name_count, i, err;
+ if (pm != 1 && pm != 2) {
+ dev_err(dev, "invalid pm configuration!");
+ return -EINVAL;
+ }
+
gpio_count = of_gpio_count(np);
if (gpio_count < 0) {
--
2.7.0.rc3
[PATCH 2/5] HSI: nokia-modem: kernel based PM
So far power management had to be done in uerspace using exported GPIOs.
This patch adds kernel based power management, which will bind the
modem's power state to the state of the phonet network interface.
Signed-off-by: Sebastian Reichel
---
drivers/hsi/clients/nokia-modem.c | 116 +++--
drivers/hsi/clients/ssi_protocol.c | 21 +++
include/linux/hsi/ssi_protocol.h | 9 +++
3 files changed, 141 insertions(+), 5 deletions(-)
diff --git a/drivers/hsi/clients/nokia-modem.c
b/drivers/hsi/clients/nokia-modem.c
index f20ede611593..6485f4c61092 100644
--- a/drivers/hsi/clients/nokia-modem.c
+++ b/drivers/hsi/clients/nokia-modem.c
@@ -28,11 +28,12 @@
#include
#include
#include
+#include
static unsigned int pm = 1;
module_param(pm, int, 0400);
MODULE_PARM_DESC(pm,
- "Enable power management (0=disabled, 1=userland based [default])");
+ "Enable power management (0=disabled, 1=userland based [default],
2=kernel based)");
enum nokia_modem_type {
RAPUYAMA_V1,
@@ -51,6 +52,7 @@ struct nokia_modem_device {
struct gpio_desc*gpio_cmt_rst_rq;
struct gpio_desc*gpio_cmt_rst;
struct gpio_desc*gpio_cmt_bsi;
+ struct notifier_block nb;
};
static void do_nokia_modem_rst_ind_tasklet(unsigned long data)
@@ -75,6 +77,93 @@ static irqreturn_t nokia_modem_rst_ind_isr(int irq, void
*data)
return IRQ_HANDLED;
}
+static void nokia_modem_power_boot(struct nokia_modem_device *modem)
+{
+ /* skip flash mode */
+ gpiod_set_value(modem->gpio_cmt_apeslpx, 0);
+ /* prevent current drain */
+ gpiod_set_value(modem->gpio_cmt_rst_rq, 0);
+
+ if (modem->type == RAPUYAMA_V1) {
+ gpiod_set_value(modem->gpio_cmt_en, 0);
+ /* toggle BSI visible to modem */
+ gpiod_set_value(modem->gpio_cmt_bsi, 0);
+ /* Assert PURX */
+ gpiod_set_value(modem->gpio_cmt_rst, 0);
+ /* Press "power key" */
+ gpiod_set_value(modem->gpio_cmt_en, 1);
+ /* Release CMT to boot */
+ gpiod_set_value(modem->gpio_cmt_rst, 1);
+ } else if(modem->type == RAPUYAMA_V2) {
+ gpiod_set_value(modem->gpio_cmt_en, 0);
+ /* 15 ms needed for ASIC poweroff */
+ usleep_range(15000, 25000);
+ gpiod_set_value(modem->gpio_cmt_en, 1);
+ }
+
+ gpiod_set_value(modem->gpio_cmt_rst_rq, 1);
+}
+
+static void nokia_modem_power_on(struct nokia_modem_device *modem)
+{
+ gpiod_set_value(modem->gpio_cmt_rst_rq, 0);
+
+ if (modem->type == RAPUYAMA_V1) {
+ /* release "power key" */
+ gpiod_set_value(modem->gpio_cmt_en, 0);
+ }
+}
+
+static void nokia_modem_power_off(struct nokia_modem_device *modem)
+{
+ /* skip flash mode */
+ gpiod_set_value(modem->gpio_cmt_apeslpx, 0);
+ /* prevent current drain */
+ gpiod_set_value(modem->gpio_cmt_rst_rq, 0);
+
+ if (modem->type == RAPUYAMA_V1) {
+ /* release "power key" */
+ gpiod_set_value(modem->gpio_cmt_en, 0);
+ /* force modem to reset state */
+ gpiod_set_value(modem->gpio_cmt_rst, 0);
+ /* release modem to be powered off by bootloader */
+ gpiod_set_value(modem->gpio_cmt_rst, 1);
+ } else if(modem->type == RAPUYAMA_V2) {
+ /* power off */
+ gpiod_set_value(modem->gpio_cmt_en, 0);
+ }
+}
+
+static int ssi_protocol_event(struct notifier_block *nb, unsigned long event,
+ void *data __maybe_unused)
+{
+ struct nokia_modem_device *modem =
+ container_of(nb, struct nokia_modem_device, nb);
+
+ switch(event) {
+ /* called on interface up */
+ case STATE_BOOT:
+ dev_info(modem->device, "modem power state: boot");
+ nokia_modem_power_boot(modem);
+ break;
+ /* called on link up */
+ case STATE_ON:
+ dev_info(modem->device, "modem power state: enabled");
+ nokia_modem_power_on(modem);
+ break;
+ /* called on interface down */
+ case STATE_OFF:
+ dev_info(modem->device, "modem power state: disabled");
+ nokia_modem_power_off(modem);
+ break;
+ default:
+ dev_warn(modem->device, "unknown ssi-protocol event");
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
static void nokia_modem_gpio_unexport(struct device *dev)
{
struct nokia_modem_device *modem = dev_get_drvdata(dev);
@@ -218,6 +307,9 @@ static int nokia_modem_probe(struct device *dev)
modem->type = RAPUYAMA_V2;
}
+
[PATCH 0/5] nokia-modem: kernel based PM
Hi, Some may remember, that in-kernel modem PM was still on the TODO list for the N9xx modem driver. This patchset adds this by hooking to the phonet interface state. In other words: 'ifconfig phonet0 up' will enable the modem and 'ifconfig phonet0 down' will disable the modem. The actual state is mapped to the carrier state (which was more or less the case already). So using the modem can be done like this now: 0. nokia-modem should be loaded with pm=2 1. ifconfig phonet0 up 2. wait for carrier on phonet0 3. communicate with the modem via isi on phonet0 4. ifconfig phonet0 down The old pm method (exporting the gpios) is still available and still the default for now. The plan is to switch the default pm method in some future kernel release (when support for the simpler interface has been added to ofono). -- Sebastian Sebastian Reichel (5): HSI: nokia-modem: simplify kernel access to gpios HSI: nokia-modem: kernel based PM HSI: ssi-protocol: export modem info via sysfs HSI: nokia-modem: drop support for disabled pm HSI: ssi-protocol: clear carrier flag on open drivers/hsi/clients/nokia-modem.c | 240 +++-- drivers/hsi/clients/ssi_protocol.c | 56 - include/linux/hsi/ssi_protocol.h | 20 3 files changed, 277 insertions(+), 39 deletions(-) -- 2.7.0.rc3
Re: [PATCHv4 2/3] IB/core: added support to use rdma cgroup controller
Hi Parav,
[auto build test ERROR on cgroup/for-next]
[cannot apply to v4.5-rc1 next-20160129]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Parav-Pandit/rdmacg-IB-core-rdma-controller-support/20160131-063313
base: https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-next
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from include/linux/cgroup_rdma.h:5:0,
from include/rdma/ib_verbs.h:58,
from include/rdma/ib_cache.h:38,
from drivers/infiniband/ulp/srp/ib_srp.c:43:
>> include/linux/parser.h:12:8: error: redefinition of 'struct match_token'
struct match_token {
^
In file included from drivers/infiniband/ulp/srp/ib_srp.c:40:0:
include/linux/parser.h:12:8: note: originally defined here
struct match_token {
^
In file included from include/linux/cgroup_rdma.h:5:0,
from include/rdma/ib_verbs.h:58,
from include/rdma/ib_cache.h:38,
from drivers/infiniband/ulp/srp/ib_srp.c:43:
>> include/linux/parser.h:17:28: error: conflicting types for 'match_table_t'
typedef struct match_token match_table_t[];
^
In file included from drivers/infiniband/ulp/srp/ib_srp.c:40:0:
include/linux/parser.h:17:28: note: previous declaration of 'match_table_t'
was here
typedef struct match_token match_table_t[];
^
In file included from include/linux/cgroup_rdma.h:5:0,
from include/rdma/ib_verbs.h:58,
from include/rdma/ib_cache.h:38,
from drivers/infiniband/ulp/srp/ib_srp.c:43:
>> include/linux/parser.h:20:7: error: redeclaration of enumerator
>> 'MAX_OPT_ARGS'
enum {MAX_OPT_ARGS = 3};
^
In file included from drivers/infiniband/ulp/srp/ib_srp.c:40:0:
include/linux/parser.h:20:7: note: previous definition of 'MAX_OPT_ARGS' was
here
enum {MAX_OPT_ARGS = 3};
^
In file included from include/linux/cgroup_rdma.h:5:0,
from include/rdma/ib_verbs.h:58,
from include/rdma/ib_cache.h:38,
from drivers/infiniband/ulp/srp/ib_srp.c:43:
>> include/linux/parser.h:26:3: error: conflicting types for 'substring_t'
} substring_t;
^
In file included from drivers/infiniband/ulp/srp/ib_srp.c:40:0:
include/linux/parser.h:26:3: note: previous declaration of 'substring_t' was
here
} substring_t;
^
In file included from include/linux/cgroup_rdma.h:5:0,
from include/rdma/ib_verbs.h:58,
from include/rdma/ib_cache.h:38,
from drivers/infiniband/ulp/srp/ib_srp.c:43:
>> include/linux/parser.h:28:5: error: conflicting types for 'match_token'
int match_token(char *, const match_table_t table, substring_t args[]);
^
In file included from drivers/infiniband/ulp/srp/ib_srp.c:40:0:
include/linux/parser.h:28:5: note: previous declaration of 'match_token' was
here
int match_token(char *, const match_table_t table, substring_t args[]);
^
In file included from include/linux/cgroup_rdma.h:5:0,
from include/rdma/ib_verbs.h:58,
from include/rdma/ib_cache.h:38,
from drivers/infiniband/ulp/srp/ib_srp.c:43:
>> include/linux/parser.h:29:5: error: conflicting types for 'match_int'
int match_int(substring_t *, int *result);
^
In file included from drivers/infiniband/ulp/srp/ib_srp.c:40:0:
include/linux/parser.h:29:5: note: previous declaration of 'match_int' was
here
int match_int(substring_t *, int *result);
^
In file included from include/linux/cgroup_rdma.h:5:0,
from include/rdma/ib_verbs.h:58,
from include/rdma/ib_cache.h:38,
from drivers/infiniband/ulp/srp/ib_srp.c:43:
>> include/linux/parser.h:30:5: error: conflicting types for 'match_octal'
int match_octal(substring_t *, int *result);
^
In file included from drivers/infiniband/ulp/srp/ib_srp.c:40:0:
include/linux/parser.h:30:5: note: previous declaration of 'match_octal' was
here
int match_octal(substring_t *, int *result);
^
In file included from include/linux/cgroup_rdma.h:5:0,
from include/rdma/ib_verbs.h:58,
from include/rdma/ib_cache.h:38,
from drivers/infiniband/ulp/srp/ib_srp.c:43:
>> include/linux/parser.h:31:5: error: conflicting types for 'match_hex'
int match_hex(substring_t *, int *result);
^
In file included from drivers/infiniband/ulp/srp/ib_srp.c:40:0:
include/linux/parser.h:31:5:
[PATCH 0/2] omap-ssi: clk change support
Hi, During diffing the n950 with the mainline kernel I noticed, that the main difference is additional DVFS support. These patches import those differences (forward-ported to pinctrl & common clock framework) to the mainline kernel. -- Sebastian Sebastian Reichel (2): ARM: dts: OMAP3-N950-N9: Add ssi idle pinctrl state HSI: omap-ssi: add clk change support arch/arm/boot/dts/omap3-n950-n9.dtsi| 16 - drivers/hsi/controllers/omap_ssi.c | 63 + drivers/hsi/controllers/omap_ssi.h | 6 drivers/hsi/controllers/omap_ssi_port.c | 20 +++ 4 files changed, 104 insertions(+), 1 deletion(-) -- 2.7.0.rc3
[PATCH 1/2] ARM: dts: OMAP3-N950-N9: Add ssi idle pinctrl state
This adds an idle pinctrl state, which will be used
by the driver to avoid incoming data during clock
rate changes or data flushing.
Signed-off-By: Sebastian Reichel
---
arch/arm/boot/dts/omap3-n950-n9.dtsi | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index aa8232828155..66c65e8008ef 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -73,6 +73,19 @@
>;
};
+ ssi_pins_idle: pinmux_ssi_pins_idle {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x217c, PIN_OUTPUT | MUX_MODE7)
/* ssi1_dat_tx */
+ OMAP3_CORE1_IOPAD(0x217e, PIN_OUTPUT | MUX_MODE7)
/* ssi1_flag_tx */
+ OMAP3_CORE1_IOPAD(0x2180, PIN_INPUT_PULLDOWN |
MUX_MODE7)/* ssi1_rdy_tx */
+ OMAP3_CORE1_IOPAD(0x2182, PIN_INPUT | WAKEUP_EN |
MUX_MODE4) /* ssi1_wake_tx (cawake) */
+ OMAP3_CORE1_IOPAD(0x2184, PIN_INPUT | MUX_MODE7)
/* ssi1_dat_rx */
+ OMAP3_CORE1_IOPAD(0x2186, PIN_INPUT | MUX_MODE7)
/* ssi1_flag_rx */
+ OMAP3_CORE1_IOPAD(0x2188, PIN_OUTPUT | MUX_MODE4)
/* ssi1_rdy_rx */
+ OMAP3_CORE1_IOPAD(0x218a, PIN_OUTPUT | MUX_MODE7)
/* ssi1_wake */
+ >;
+ };
+
modem_pins1: pinmux_modem_core1_pins {
pinctrl-single,pins = <
OMAP3_CORE1_IOPAD(0x207a, PIN_INPUT | WAKEUP_EN |
MUX_MODE4) /* gpio_34 (ape_rst_rq) */
@@ -237,8 +250,9 @@
};
_port1 {
- pinctrl-names = "default";
+ pinctrl-names = "default", "idle";
pinctrl-0 = <_pins>;
+ pinctrl-1 = <_pins_idle>;
ti,ssi-cawake-gpio = < 23 GPIO_ACTIVE_HIGH>; /* 151 */
--
2.7.0.rc3
[PATCH 2/2] HSI: omap-ssi: add clk change support
This adds support for frequency changes of the SSI
functional clock, which may occur due to DVFS.
Signed-off-By: Sebastian Reichel
---
drivers/hsi/controllers/omap_ssi.c | 63 +
drivers/hsi/controllers/omap_ssi.h | 6
drivers/hsi/controllers/omap_ssi_port.c | 20 +++
3 files changed, 89 insertions(+)
diff --git a/drivers/hsi/controllers/omap_ssi.c
b/drivers/hsi/controllers/omap_ssi.c
index f6d3100b7a32..8bc5f2fed869 100644
--- a/drivers/hsi/controllers/omap_ssi.c
+++ b/drivers/hsi/controllers/omap_ssi.c
@@ -291,6 +291,64 @@ static unsigned long ssi_get_clk_rate(struct
hsi_controller *ssi)
return rate;
}
+static int ssi_clk_event(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+ struct omap_ssi_controller *omap_ssi = container_of(nb,
+ struct omap_ssi_controller, fck_nb);
+ struct hsi_controller *ssi = to_hsi_controller(omap_ssi->dev);
+ struct clk_notifier_data *clk_data = data;
+ struct omap_ssi_port *omap_port;
+ int i;
+
+ switch (event) {
+ case PRE_RATE_CHANGE:
+ dev_dbg(>device, "pre rate change\n");
+
+ for (i = 0; i < ssi->num_ports; i++) {
+ omap_port = omap_ssi->port[i];
+
+ if (!omap_port)
+ continue;
+
+ /* Workaround for SWBREAK + CAwake down race in CMT */
+ tasklet_disable(_port->wake_tasklet);
+
+ /* stop all ssi communication */
+ pinctrl_pm_select_idle_state(omap_port->pdev);
+ udelay(1); /* wait for racing frames */
+ }
+
+ break;
+ case ABORT_RATE_CHANGE:
+ dev_dbg(>device, "abort rate change\n");
+ /* Fall through */
+ case POST_RATE_CHANGE:
+ dev_dbg(>device, "post rate change (%lu -> %lu)\n",
+ clk_data->old_rate, clk_data->new_rate);
+ omap_ssi->fck_rate = DIV_ROUND_CLOSEST(clk_data->new_rate,
1000); /* KHz */
+
+ for (i = 0; i < ssi->num_ports; i++) {
+ omap_port = omap_ssi->port[i];
+
+ if (!omap_port)
+ continue;
+
+ omap_ssi_port_update_fclk(ssi, omap_port);
+
+ /* resume ssi communication */
+ pinctrl_pm_select_default_state(omap_port->pdev);
+ tasklet_enable(_port->wake_tasklet);
+ }
+
+ break;
+ default:
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
static int __init ssi_get_iomem(struct platform_device *pd,
const char *name, void __iomem **pbase, dma_addr_t *phy)
{
@@ -371,6 +429,10 @@ static int __init ssi_add_controller(struct hsi_controller
*ssi,
goto out_err;
}
+ omap_ssi->fck_nb.notifier_call = ssi_clk_event;
+ omap_ssi->fck_nb.priority = INT_MAX;
+ clk_notifier_register(omap_ssi->fck, _ssi->fck_nb);
+
/* TODO: find register, which can be used to detect context loss */
omap_ssi->get_loss = NULL;
@@ -434,6 +496,7 @@ static void ssi_remove_controller(struct hsi_controller
*ssi)
int id = ssi->id;
tasklet_kill(_ssi->gdd_tasklet);
hsi_unregister_controller(ssi);
+ clk_notifier_unregister(omap_ssi->fck, _ssi->fck_nb);
ida_simple_remove(_omap_ssi_ida, id);
}
diff --git a/drivers/hsi/controllers/omap_ssi.h
b/drivers/hsi/controllers/omap_ssi.h
index f9aaf37262be..2797ab284460 100644
--- a/drivers/hsi/controllers/omap_ssi.h
+++ b/drivers/hsi/controllers/omap_ssi.h
@@ -134,6 +134,8 @@ struct gdd_trn {
* @gdd_tasklet: bottom half for DMA transfers
* @gdd_trn: Array of GDD transaction data for ongoing GDD transfers
* @lock: lock to serialize access to GDD
+ * @fck_nb: DVFS notfifier block
+ * @fck_rate: clock rate
* @loss_count: To follow if we need to restore context or not
* @max_speed: Maximum TX speed (Kb/s) set by the clients.
* @sysconfig: SSI controller saved context
@@ -151,6 +153,7 @@ struct omap_ssi_controller {
struct tasklet_struct gdd_tasklet;
struct gdd_trn gdd_trn[SSI_MAX_GDD_LCH];
spinlock_t lock;
+ struct notifier_block fck_nb;
unsigned long fck_rate;
u32 loss_count;
u32 max_speed;
@@ -164,4 +167,7 @@ struct omap_ssi_controller {
#endif
};
+void omap_ssi_port_update_fclk(struct hsi_controller *ssi,
+ struct omap_ssi_port *omap_port);
+
#endif /* __LINUX_HSI_OMAP_SSI_H__ */
diff --git a/drivers/hsi/controllers/omap_ssi_port.c
b/drivers/hsi/controllers/omap_ssi_port.c
index
[PATCH] rdmacg: fix semicolon.cocci warnings
kernel/cgroup_rdma.c:787:2-3: Unneeded semicolon kernel/cgroup_rdma.c:611:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Parav Pandit Signed-off-by: Fengguang Wu --- cgroup_rdma.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/kernel/cgroup_rdma.c +++ b/kernel/cgroup_rdma.c @@ -608,7 +608,7 @@ static enum rdmacg_resource_pool_type of default: pool_type = RDMACG_RESOURCE_POOL_HW; break; - }; + } return pool_type; } @@ -784,7 +784,7 @@ static int get_resource_val(struct rdmac default: val = 0; break; - }; + } return val; }
Re: [patch] staging: rtl8712: memory corruption in wpa_set_encryption()
On Saturday, January 30, 2016 05:41:10 PM Dan Carpenter wrote:
> ->KeyMaterial is declared as a 16 byte array, but we only ever allocate
> either 5 or 13 bytes of it. The problem is that we memset() all 16
> bytes to zero so we're memsetting past the end of the allocated memory.
>
> I fixed this in slightly lazy way, by just allocating 16 bytes. This
> works but there is a lot more cleanup you could do to this code if you
> wanted. Which is why this code is in staging.
Better in every way than a crazy variable alloc if you ask me.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> index edfc680..db2e31bc 100644
> --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> @@ -398,12 +398,9 @@ static int wpa_set_encryption(struct net_device *dev,
> struct ieee_param *param,
> wep_key_idx = 0;
> if (wep_key_len > 0) {
> wep_key_len = wep_key_len <= 5 ? 5 : 13;
> - pwep = kmalloc((u32)(wep_key_len +
> - FIELD_OFFSET(struct NDIS_802_11_WEP,
> - KeyMaterial)), GFP_ATOMIC);
> + pwep = kzalloc(sizeof(*pwep), GFP_ATOMIC);
> if (pwep == NULL)
> return -ENOMEM;
> - memset(pwep, 0, sizeof(struct NDIS_802_11_WEP));
Should there be a newline after the "if" statement?
> pwep->KeyLength = wep_key_len;
> pwep->Length = wep_key_len +
>FIELD_OFFSET(struct NDIS_802_11_WEP,
Re: [PATCHv4 1/3] rdmacg: Added rdma cgroup controller.
Hi Parav,
[auto build test ERROR on cgroup/for-next]
[also build test ERROR on v4.5-rc1 next-20160129]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Parav-Pandit/rdmacg-IB-core-rdma-controller-support/20160131-063313
base: https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-next
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from arch/x86/include/asm/bug.h:35:0,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/gfp.h:4,
from include/linux/slab.h:14,
from kernel/cgroup_rdma.c:8:
kernel/cgroup_rdma.c: In function 'find_cg_rpool_locked':
>> include/linux/lockdep.h:340:51: error: invalid type argument of '->' (have
>> 'spinlock_t {aka struct spinlock}')
#define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map)
^
include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
int __ret_warn_on = !!(condition);\
^
>> include/linux/lockdep.h:366:27: note: in expansion of macro 'lockdep_is_held'
WARN_ON(debug_locks && !lockdep_is_held(l)); \
^
>> kernel/cgroup_rdma.c:179:2: note: in expansion of macro 'lockdep_assert_held'
lockdep_assert_held(cg->rpool_list_lock);
^
coccinelle warnings: (new ones prefixed by >>)
>> kernel/cgroup_rdma.c:912:1-7: preceding lock on line 879
--
>> kernel/cgroup_rdma.c:787:2-3: Unneeded semicolon
kernel/cgroup_rdma.c:611:2-3: Unneeded semicolon
Please review and possibly fold the followup patch.
vim +340 include/linux/lockdep.h
7531e2f34 Peter Zijlstra 2008-08-11 334int trylock,
int read, int check,
7531e2f34 Peter Zijlstra 2008-08-11 335struct
lockdep_map *nest_lock, unsigned long ip);
fbb9ce953 Ingo Molnar 2006-07-03 336
fbb9ce953 Ingo Molnar 2006-07-03 337 extern void lock_release(struct
lockdep_map *lock, int nested,
fbb9ce953 Ingo Molnar 2006-07-03 338unsigned long
ip);
fbb9ce953 Ingo Molnar 2006-07-03 339
f607c6685 Peter Zijlstra 2009-07-20 @340 #define lockdep_is_held(lock)
lock_is_held(&(lock)->dep_map)
f607c6685 Peter Zijlstra 2009-07-20 341
f607c6685 Peter Zijlstra 2009-07-20 342 extern int lock_is_held(struct
lockdep_map *lock);
f607c6685 Peter Zijlstra 2009-07-20 343
00ef9f734 Peter Zijlstra 2008-12-04 344 extern void lock_set_class(struct
lockdep_map *lock, const char *name,
00ef9f734 Peter Zijlstra 2008-12-04 345 struct
lock_class_key *key, unsigned int subclass,
64aa348ed Peter Zijlstra 2008-08-11 346 unsigned
long ip);
64aa348ed Peter Zijlstra 2008-08-11 347
00ef9f734 Peter Zijlstra 2008-12-04 348 static inline void
lock_set_subclass(struct lockdep_map *lock,
00ef9f734 Peter Zijlstra 2008-12-04 349 unsigned int subclass,
unsigned long ip)
00ef9f734 Peter Zijlstra 2008-12-04 350 {
00ef9f734 Peter Zijlstra 2008-12-04 351 lock_set_class(lock,
lock->name, lock->key, subclass, ip);
00ef9f734 Peter Zijlstra 2008-12-04 352 }
00ef9f734 Peter Zijlstra 2008-12-04 353
cf40bd16f Nick Piggin 2009-01-21 354 extern void
lockdep_set_current_reclaim_state(gfp_t gfp_mask);
cf40bd16f Nick Piggin 2009-01-21 355 extern void
lockdep_clear_current_reclaim_state(void);
cf40bd16f Nick Piggin 2009-01-21 356 extern void
lockdep_trace_alloc(gfp_t mask);
cf40bd16f Nick Piggin 2009-01-21 357
a24fc60d6 Peter Zijlstra 2015-06-11 358 extern void lock_pin_lock(struct
lockdep_map *lock);
a24fc60d6 Peter Zijlstra 2015-06-11 359 extern void lock_unpin_lock(struct
lockdep_map *lock);
a24fc60d6 Peter Zijlstra 2015-06-11 360
cf40bd16f Nick Piggin 2009-01-21 361 # define INIT_LOCKDEP
.lockdep_recursion = 0, .lockdep_reclaim_gfp = 0,
fbb9ce953 Ingo Molnar 2006-07-03 362
e3a55fd18 Jarek Poplawski 2007-03-22 363 #define lockdep_depth(tsk)
(debug_locks ? (tsk)->lockdep_depth : 0)
d5abe6691 Peter Zijlstra 2006-12-06 364
b1ae345d9 Johannes Berg 2013-02-21 365 #define lockdep_assert_held(l)
do {\
b1ae345d9 Johannes Berg 2013-02-21 @366 WARN_ON(debug_locks &&
!lockdep_is_held(l));\
b1ae345d9 Johannes Berg 2013-02-21 367 } while (0)
f607c6685 Peter Zijlstra 2009-07-20 368
9a37110d2 Peter Hurley2014-09-10 369 #define lockdep_assert_held_once(l)
do {\
:: The code at line 340 was first introduced by commit
::
Re: 3-color led too bright
Hi Pavel, On Sat, Jan 30, 2016 at 09:07:50PM +0100, Pavel Machek wrote: > The indicator 3-color LED in mainline kernel seem to be a bit too > bright. .. more bright to look at comfortably. I believe it is also > brighter than in original maemo... I believe I've seen note somewhere > that hardware may allow too much current to the 3-color led damaging > hardware... but I can't find the link now. Safe current limits for the leds are configured in the DTS (led-cur and max-cur) and can be checked in sysfs. I remember testing the safety limits when I added them to DT, but the driver has changed a bit since then. -- Sebastian signature.asc Description: PGP signature
Re: timers: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
On Fri, Jan 29, 2016 at 04:27:35PM +0100, Peter Zijlstra wrote: > On Fri, Jan 15, 2016 at 03:14:10PM -0800, Paul E. McKenney wrote: > > And if I make the scheduling-clock interrupt send extra wakeups to the RCU > > grace-period kthread when needed, things work even with CPU hotplug going. > > > > The "when needed" means any time that the RCU grace-period kthread has > > been sleeping three times as long as the timeout interval. If the first > > wakeup does nothing, it does another wakeup once per second. > > > > So it looks like this change makes an existing problem much worse, as > > opposed to introducing a new problem. > > I have a vague idea about a possible race window. Have you been > observing this on PPC or x86? > > The reason I'm asking is that PPC (obviously) allows for more races :-) ;-) I have been seeing this on x86. Thanx, Paul
Re: [PATCH v2] locktorture: Fix NULL pointer when torture_type is invalid
On Sat, Jan 30, 2016 at 10:46:57AM +0800, Kefeng Wang wrote:
> Hi Paul,
>
> On 2016/1/28 12:25, Kefeng Wang wrote:
> > Insmod locktorture with torture_type=mutex will lead to crash,
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 0008
> > pgd = ffc0f6c1
> > [0008] *pgd=00013b221003, *pud=00013b221003,
> > *pmd=a
> > Internal error: Oops: 9406 [#1] PREEMPT SMP
> > Modules linked in: locktorture(+) torture
> > CPU: 2 PID: 1462 Comm: insmod Not tainted 4.4.0+ #19
> > Hardware name: linux,dummy-virt (DT)
> > task: ffc0fb2b3700 ti: ffc0fa938000 task.ti: ffc0fa938000
> > PC is at __torture_print_stats+0x18/0x180 [locktorture]
> > LR is at lock_torture_stats_print+0x68/0x110 [locktorture]
> > pc : [] lr : [] pstate: 6145
> > sp : ffc0fa93bb20
> > [snip...]
> > Call trace:
> > [] __torture_print_stats+0x18/0x180 [locktorture]
> > [] lock_torture_stats_print+0x68/0x110 [locktorture]
> > [] lock_torture_cleanup+0xc4/0x278 [locktorture]
> > [] lock_torture_init+0x144/0x5b0 [locktorture]
> > [] do_one_initcall+0x94/0x1a0
> > [] do_init_module+0x60/0x1c8
> > [] load_module+0x1880/0x1c9c
> > [] SyS_finit_module+0x7c/0x88
> > [] el0_svc_naked+0x24/0x28
> >
> > Fix it by check statp in __torture_print_stats(), if it is NULL, just
> > create a lock-torture-statistics message with zero statistic argument.
>
> It is keep to get the statistics printout at the end if with bad argument,
> what's your opinion about this version？
Hello, Kefeng,
Well, it does look like it would prevent the NULL pointer dereference,
but I was hoping for something that would print the full statistics
at the end regardless of the periodic statistics.
But I am adding Davidlohr on CC, as he seems to be the major user
of locktorture.
Thanx, Paul
> Thanks,
> Kefeng
>
> >
> > Cc: Josh Triplett
> > Cc: Paul E. McKenney
> > Signed-off-by: Kefeng Wang
> > ---
> > kernel/locking/locktorture.c | 24 ++--
> > 1 file changed, 14 insertions(+), 10 deletions(-)
> >
> > diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> > index 8ef1919..7f0cf9c 100644
> > --- a/kernel/locking/locktorture.c
> > +++ b/kernel/locking/locktorture.c
> > @@ -647,19 +647,23 @@ static void __torture_print_stats(char *page,
> > bool fail = 0;
> > int i, n_stress;
> > long max = 0;
> > - long min = statp[0].n_lock_acquired;
> > + long min = 0;
> > long long sum = 0;
> >
> > - n_stress = write ? cxt.nrealwriters_stress : cxt.nrealreaders_stress;
> > - for (i = 0; i < n_stress; i++) {
> > - if (statp[i].n_lock_fail)
> > - fail = true;
> > - sum += statp[i].n_lock_acquired;
> > - if (max < statp[i].n_lock_fail)
> > - max = statp[i].n_lock_fail;
> > - if (min > statp[i].n_lock_fail)
> > - min = statp[i].n_lock_fail;
> > + if (statp) {
> > + min = statp[0].n_lock_acquired;
> > + n_stress = write ? cxt.nrealwriters_stress :
> > cxt.nrealreaders_stress;
> > + for (i = 0; i < n_stress; i++) {
> > + if (statp[i].n_lock_fail)
> > + fail = true;
> > + sum += statp[i].n_lock_acquired;
> > + if (max < statp[i].n_lock_fail)
> > + max = statp[i].n_lock_fail;
> > + if (min > statp[i].n_lock_fail)
> > + min = statp[i].n_lock_fail;
> > + }
> > }
> > +
> > page += sprintf(page,
> > "%s: Total: %lld Max/Min: %ld/%ld %s Fail: %d %s\n",
> > write ? "Writes" : "Reads ",
> >
>
Re: [PATCHv4 1/3] rdmacg: Added rdma cgroup controller.
Hi Parav, [auto build test ERROR on cgroup/for-next] [also build test ERROR on v4.5-rc1 next-20160129] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Parav-Pandit/rdmacg-IB-core-rdma-controller-support/20160131-063313 base: https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-next config: xtensa-allmodconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=xtensa All errors (new ones prefixed by >>): In file included from arch/xtensa/include/generated/asm/bug.h:1:0, from include/linux/bug.h:4, from include/linux/mmdebug.h:4, from include/linux/gfp.h:4, from include/linux/slab.h:14, from kernel/cgroup_rdma.c:8: kernel/cgroup_rdma.c: In function 'find_cg_rpool_locked': >> include/linux/lockdep.h:340:51: error: invalid type argument of '->' (have >> 'spinlock_t') #define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map) ^ include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON' int __ret_warn_on = !!(condition);\ ^ include/linux/lockdep.h:366:27: note: in expansion of macro 'lockdep_is_held' WARN_ON(debug_locks && !lockdep_is_held(l)); \ ^ kernel/cgroup_rdma.c:179:2: note: in expansion of macro 'lockdep_assert_held' lockdep_assert_held(cg->rpool_list_lock); ^ vim +340 include/linux/lockdep.h 7531e2f34 Peter Zijlstra 2008-08-11 334 int trylock, int read, int check, 7531e2f34 Peter Zijlstra 2008-08-11 335 struct lockdep_map *nest_lock, unsigned long ip); fbb9ce953 Ingo Molnar2006-07-03 336 fbb9ce953 Ingo Molnar2006-07-03 337 extern void lock_release(struct lockdep_map *lock, int nested, fbb9ce953 Ingo Molnar2006-07-03 338 unsigned long ip); fbb9ce953 Ingo Molnar2006-07-03 339 f607c6685 Peter Zijlstra 2009-07-20 @340 #define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map) f607c6685 Peter Zijlstra 2009-07-20 341 f607c6685 Peter Zijlstra 2009-07-20 342 extern int lock_is_held(struct lockdep_map *lock); f607c6685 Peter Zijlstra 2009-07-20 343 :: The code at line 340 was first introduced by commit :: f607c6685774811b8112e124f10a053d77015485 lockdep: Introduce lockdep_assert_held() :: TO: Peter Zijlstra :: CC: Ingo Molnar --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
[PULL REQUEST] i2c for 4.5
Linus, here are two I2C driver regression fixes. piix4 gets a larger overhaul fixing the latest refactoring and also an older known issue as well. designware-pci gets a fix for a bad merge conflict resolution. Please pull. Thanks, Wolfram The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d: Linux 4.5-rc1 (2016-01-24 13:06:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current for you to fetch changes up to 52795f6fdeb8a2b98373108ac2838c674bb2cbc4: i2c: piix4: don't regress on bus names (2016-01-29 11:13:52 +0100) Andy Shevchenko (1): i2c: designware-pci: use IRQF_COND_SUSPEND flag Jean Delvare (3): i2c: piix4: Fix SB800 locking i2c: piix4: Fully initialize SB800 before it is registered i2c: piix4: don't regress on bus names drivers/i2c/busses/i2c-designware-core.c | 3 +- drivers/i2c/busses/i2c-piix4.c | 50 ++-- 2 files changed, 23 insertions(+), 30 deletions(-)
[PATCH] ARM: dts: imx6qdl-udoo: add sound support
Add sound support in UDOO board DT file.
Signed-off-by: Maciej S. Szmigiero
---
arch/arm/boot/dts/imx6qdl-udoo.dtsi | 57 +
1 file changed, 57 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index 1211da894ee9..d3e54e40a017 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -34,6 +34,18 @@
gpio = < 12 0>;
};
};
+
+ sound {
+ compatible = "fsl,imx6q-udoo-ac97",
+"fsl,imx-audio-ac97";
+ model = "fsl,imx6q-udoo-ac97";
+ audio-cpu = <>;
+ audio-routing =
+ "RX", "Mic Jack",
+ "Headphone Jack", "TX";
+ mux-int-port = <1>;
+ mux-ext-port = <6>;
+ };
};
{
@@ -109,6 +121,36 @@
MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
>;
};
+
+ pinctrl_ac97_running: ac97running {
+ fsl,pins = <
+ MX6QDL_PAD_DI0_PIN2__AUD6_TXD 0x1b0b0
+ MX6QDL_PAD_DI0_PIN3__AUD6_TXFS 0x1b0b0
+ MX6QDL_PAD_DI0_PIN4__AUD6_RXD 0x1b0b0
+ MX6QDL_PAD_DI0_PIN15__AUD6_TXC 0x1b0b0
+ MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
+ >;
+ };
+
+ pinctrl_ac97_warm_reset: ac97warmreset {
+ fsl,pins = <
+ MX6QDL_PAD_DI0_PIN2__AUD6_TXD 0x1b0b0
+ MX6QDL_PAD_DI0_PIN3__GPIO4_IO19 0x1b0b0
+ MX6QDL_PAD_DI0_PIN4__AUD6_RXD 0x1b0b0
+ MX6QDL_PAD_DI0_PIN15__AUD6_TXC 0x1b0b0
+ MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
+ >;
+ };
+
+ pinctrl_ac97_reset: ac97reset {
+ fsl,pins = <
+ MX6QDL_PAD_DI0_PIN2__GPIO4_IO18 0x1b0b0
+ MX6QDL_PAD_DI0_PIN3__GPIO4_IO19 0x1b0b0
+ MX6QDL_PAD_DI0_PIN4__AUD6_RXD 0x1b0b0
+ MX6QDL_PAD_DI0_PIN15__AUD6_TXC 0x1b0b0
+ MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
+ >;
+ };
};
};
@@ -132,3 +174,18 @@
non-removable;
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ cell-index = <0>;
+ fsl,mode = "ac97-slave";
+ pinctrl-names = "ac97-running", "ac97-reset", "ac97-warm-reset";
+ pinctrl-0 = <_ac97_running>;
+ pinctrl-1 = <_ac97_reset>;
+ pinctrl-2 = <_ac97_warm_reset>;
+ ac97-gpios = < 19 0 18 0 30 0>;
+ status = "okay";
+};
drivers/isdn/mISDN/dsp_blowfish.c:662:1: warning: the frame size of 1632 bytes is larger than 1024 bytes
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: ad0b40fa944628d6f30b40266a599b285d70a266
commit: c6d308534aef6c99904bf5862066360ae067abc4 UBSAN: run-time undefined
behavior sanity checker
date: 10 days ago
config: i386-randconfig-x0-01310609 (attached as .config)
reproduce:
git checkout c6d308534aef6c99904bf5862066360ae067abc4
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/isdn/mISDN/dsp_blowfish.c: In function 'dsp_bf_init':
>> drivers/isdn/mISDN/dsp_blowfish.c:662:1: warning: the frame size of 1632
>> bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
^
vim +662 drivers/isdn/mISDN/dsp_blowfish.c
960366cf Karsten Keil 2008-07-27 646 encrypt_block(P, S, data, data);
960366cf Karsten Keil 2008-07-27 647
960366cf Karsten Keil 2008-07-27 648 P[i] = data[0];
960366cf Karsten Keil 2008-07-27 649 P[i + 1] = data[1];
960366cf Karsten Keil 2008-07-27 650 }
960366cf Karsten Keil 2008-07-27 651
960366cf Karsten Keil 2008-07-27 652 for (i = 0; i < 4; i++) {
960366cf Karsten Keil 2008-07-27 653 for (j = 0, count = i * 256; j
< 256; j += 2, count += 2) {
960366cf Karsten Keil 2008-07-27 654 encrypt_block(P, S,
data, data);
960366cf Karsten Keil 2008-07-27 655
960366cf Karsten Keil 2008-07-27 656 S[count] = data[0];
960366cf Karsten Keil 2008-07-27 657 S[count + 1] = data[1];
960366cf Karsten Keil 2008-07-27 658 }
960366cf Karsten Keil 2008-07-27 659 }
960366cf Karsten Keil 2008-07-27 660
960366cf Karsten Keil 2008-07-27 661 return 0;
960366cf Karsten Keil 2008-07-27 @662 }
960366cf Karsten Keil 2008-07-27 663
960366cf Karsten Keil 2008-07-27 664
960366cf Karsten Keil 2008-07-27 665 /*
960366cf Karsten Keil 2008-07-27 666 * turn encryption off
960366cf Karsten Keil 2008-07-27 667 */
960366cf Karsten Keil 2008-07-27 668 void
960366cf Karsten Keil 2008-07-27 669 dsp_bf_cleanup(struct dsp *dsp)
960366cf Karsten Keil 2008-07-27 670 {
:: The code at line 662 was first introduced by commit
:: 960366cf8dbb3359afaca30cf7fdbf69a6d6dda7 Add mISDN DSP
:: TO: Karsten Keil
:: CC: Karsten Keil
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [dm-devel] [PATCH v2] dm pref-path: provides preferred path load balance policy
On Sat, Jan 30, 2016 at 02:25:25PM -0600, Benjamin Marzinski wrote: > Before this commit, it always used the pref bit. Again, like I said > before, I'm saying that this was the wrong thing to do. The Spec is Oops. I meant: "I'm NOT saying that this was the wrong thing to do". I am also fine with changing the default back to making the pref bit always create it's own path group. As long there is a way for users to get either behavior, I'm happy. -Ben > pretty vague on what you should expect to happen when you set to pref > bit. When the path was in a group by itself, I got complaints. Now that > the path is is a group with other active/optimized paths, I get > complaints. The only answer is to allow the user to say what they want > the pref bit to mean. > > -Ben
Re: [PATCH net v2 1/4] net/core: relax BUILD_BUG_ON in netdev_stats_to_stats64
From: Jarod Wilson Date: Sat, 30 Jan 2016 15:53:05 -0500 > On Sat, Jan 30, 2016 at 03:39:01PM -0500, Jarod Wilson wrote: >> Ew, no, it won't work correctly on 32-bit. The for loop is going to copy >> data into dst from beyond the end of netdev_stats, and the range looks >> like it won't be right either, only half of the added stats64 space will >> get zeroed out. Okay, I'll fix that up correctly. > > Completely untested as of yet, but I think something like the following > looks correct. I'll give it a spin as soon as I can. Jarod, please respin your entire series as a v3 once you sort this out. Thanks.
Re: [REGRESSION] gpio: pxa: change initcall level second attempt
Marcel, would you try the patch here after ?
I have tested it on my cm-x300 with a devicetree build, let's see if that is a
solution to your issue.
Cheers.
--
Robert
---8<---
>From 5901e6d55061c0cd627cfbf090ef6362c712b3c8 Mon Sep 17 00:00:00 2001
From: Robert Jarzmik
Date: Sun, 31 Jan 2016 00:06:21 +0100
Subject: [PATCH] net: ethernet: davicom: fix devicetree irq resource
The dm9000 driver doesn't work in at least one device-tree
configuration, spitting an error message on irq resource :
[1.062495] dm9000 800.ethernet: insufficient resources
[1.068439] dm9000 800.ethernet: not found (-2).
[1.073451] dm9000: probe of 800.ethernet failed with error -2
The reason behind is that the interrupt might be provided by a gpio
controller, not probed when dm9000 is probed, and needing the probe
deferral mechanism to apply.
Currently, the interrupt is directly taken from resources. This patch
changes this to use the more generic platform_get_irq(), which handles
the deferral.
Moreover, since commit Fixes: 7085a7401ba5 ("drivers: platform: parse
IRQ flags from resources"), the interrupt trigger flags are honored in
platform_get_irq(), so remove the needless code in dm9000.
Signed-off-by: Robert Jarzmik
---
drivers/net/ethernet/davicom/dm9000.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/davicom/dm9000.c
b/drivers/net/ethernet/davicom/dm9000.c
index cf94b72..22e1a9d 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -128,7 +128,6 @@ struct board_info {
struct resource *data_res;
struct resource *addr_req; /* resources requested */
struct resource *data_req;
- struct resource *irq_res;
int irq_wake;
@@ -1300,18 +1299,14 @@ static int
dm9000_open(struct net_device *dev)
{
struct board_info *db = netdev_priv(dev);
- unsigned long irqflags = db->irq_res->flags & IRQF_TRIGGER_MASK;
+ unsigned long irqflags = 0;
if (netif_msg_ifup(db))
dev_dbg(db->dev, "enabling %s\n", dev->name);
- /* If there is no IRQ type specified, default to something that
-* may work, and tell the user that this is a problem */
-
- if (irqflags == IRQF_TRIGGER_NONE)
- irqflags = irq_get_trigger_type(dev->irq);
-
- if (irqflags == IRQF_TRIGGER_NONE)
+ /* If there is no IRQ type specified, tell the user that this is a
+* problem */
+ if (irq_get_trigger_type(dev->irq) == IRQF_TRIGGER_NONE)
dev_warn(db->dev, "WARNING: no IRQ resource flags set.\n");
irqflags |= IRQF_SHARED;
@@ -1500,15 +1495,21 @@ dm9000_probe(struct platform_device *pdev)
db->addr_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
db->data_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- db->irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (db->addr_res == NULL || db->data_res == NULL ||
- db->irq_res == NULL) {
- dev_err(db->dev, "insufficient resources\n");
+ if (db->addr_res == NULL || db->data_res == NULL) {
+ dev_err(db->dev, "insufficient resources addr=%p data=%p\n",
+ db->addr_res, db->data_res);
ret = -ENOENT;
goto out;
}
+ ndev->irq = platform_get_irq(pdev, 0);
+ if (ndev->irq <= 0) {
+ dev_err(db->dev, "interrupt ressource unavailable: %d\n",
+ ndev->irq);
+ return ndev->irq;
+ }
+
db->irq_wake = platform_get_irq(pdev, 1);
if (db->irq_wake >= 0) {
dev_dbg(db->dev, "wakeup irq %d\n", db->irq_wake);
@@ -1570,7 +1571,6 @@ dm9000_probe(struct platform_device *pdev)
/* fill in parameters for net-dev structure */
ndev->base_addr = (unsigned long)db->io_addr;
- ndev->irq = db->irq_res->start;
/* ensure at least we have a default set of IO routines */
dm9000_set_io(db, iosize);
--
2.1.4
[PATCHv4 3/3] rdmacg: Added documentation for rdma controller
Added documentation for rdma controller to use in v1 mode and using new unified hirerchy mode v2. Signed-off-by: Parav Pandit --- Documentation/cgroup-v1/rdma.txt | 117 +++ Documentation/cgroup-v2.txt | 43 ++ 2 files changed, 160 insertions(+) create mode 100644 Documentation/cgroup-v1/rdma.txt diff --git a/Documentation/cgroup-v1/rdma.txt b/Documentation/cgroup-v1/rdma.txt new file mode 100644 index 000..688f04b --- /dev/null +++ b/Documentation/cgroup-v1/rdma.txt @@ -0,0 +1,117 @@ + RDMA Controller + + +Contents + + +1. Overview + 1-1. What is RDMA controller? + 1-2. Why RDMA controller needed? + 1-3. How is RDMA controller implemented? +2. Usage Examples + +1. Overview + +1-1. What is RDMA controller? +- + +RDMA controller allows user to limit RDMA/IB specific resources +that a given set of processes can use. These processes are grouped using +RDMA controller. + +RDMA controller currently allows two different type of resource pools. +(a) RDMA IB specification level verb resources defined by IB stack +(b) HCA vendor device specific resources + +1-2. Why RDMA controller needed? + + +Currently user space applications can easily take away all the rdma device +specific resources such as AH, CQ, QP, MR etc. Due to which other applications +in other cgroup or kernel space ULPs may not even get chance to allocate any +rdma resources. This leads to service unavailability. + +Therefore RDMA controller is needed through which resource consumption +of processes can be limited. Through this controller various different rdma +resources described by IB uverbs layer and any HCA vendor driver can be +accounted. + +1-3. How is RDMA controller implemented? + + +RDMA cgroup allows limit configuration of resources. These resources are not +defined by the rdma controller. Instead they are defined by the IB stack +and HCA device drivers(optionally). +This provides great flexibility to allow IB stack to define new resources, +without any changes to rdma cgroup. +Rdma cgroup maintains resource accounting per cgroup, per device, per resource +type using resource pool structure. Each such resource pool is limited up to +64 resources in given resource pool by rdma cgroup, which can be extended +later if required. + +This resource pool object is linked to the cgroup css. Typically there +are 0 to 4 resource pool instances per cgroup, per device in most use cases. +But nothing limits to have it more. At present hundreds of RDMA devices per +single cgroup may not be handled optimally, however there is no known use case +for such configuration either. + +Since RDMA resources can be allocated from any process and can be freed by any +of the child processes which shares the address space, rdma resources are +always owned by the creator cgroup css. This allows process migration from one +to other cgroup without major complexity of transferring resource ownership; +because such ownership is not really present due to shared nature of +rdma resources. Linking resources around css also ensures that cgroups can be +deleted after processes migrated. This allow progress migration as well with +active resources, even though that’s not the primary use case. + +Whenever RDMA resource charing occurs, owner rdma cgroup is returned to +the caller. Same rdma cgroup should be passed while uncharging the resource. +This also allows process migrated with active RDMA resource to charge +to new owner cgroup for new resource. It also allows to uncharge resource of +a process from previously charged cgroup which is migrated to new cgroup, +even though that is not a primary use case. + +Resource pool object is created in following situations. +(a) User sets the limit and no previous resource pool exist for the device +of interest for the cgroup. +(b) No resource limits were configured, but IB/RDMA stack tries to +charge the resource. So that it correctly uncharge them when applications are +running without limits and later on when limits are enforced during uncharging, +otherwise usage count will drop to negative. This is done using default +resource pool. Instead of implementing any sort of time markers, default pool +simplifies the design. + +Resource pool is destroyed if it was of default type (not created +by administrative operation) and it’s the last resource getting +deallocated. Resource pool created as administrative operation is not +deleted, as it’s expected to be used in near future. + +If user setting tries to delete all the resource limit +with active resources per device, RDMA cgroup just marks the pool as +default pool with maximum limits for each resource, otherwise it deletes the +default resource pool. + +2. Usage Examples +- + +(a) Configure resource limit: +echo mlx4_0
[PATCHv4 1/3] rdmacg: Added rdma cgroup controller.
Added rdma cgroup controller that does accounting, limit enforcement
on rdma/IB verbs and hw resources.
Added rdma cgroup header file which defines its APIs to perform
charing/uncharing functionality and device registration which will
participate in controller functions of accounting and limit
enforcements. It also define rdmacg_device structure to bind IB stack
and RDMA cgroup controller.
RDMA resources are tracked using resource pool. Resource pool is per
device, per cgroup, per resource pool_type entity which allows setting
up accounting limits on per device basis.
RDMA cgroup returns error when user space applications try to allocate
resources more than its configured limit.
Rdma cgroup implements resource accounting for two types of resource
pools.
(a) RDMA IB specification level verb resources defined by IB stack
(b) HCA vendor device specific resources defined by vendor device driver
Resources are not defined by the RDMA cgroup, instead they are defined
by the external module, typically IB stack and optionally by HCA drivers
for those RDMA devices which doesn't have one to one mapping of IB verb
resource with hardware resource. This allows extending IB stack without
changing kernel, which is frequent as IB stack is going through changes
and enhancements.
Resource pool are created/destroyed dynamically whenever
charging/uncharging occurs respectively and whenever user configuration
is done. Its a tradeoff of memory vs little more code space that creates
resource pool whenever necessary, instead of creating them during cgroup
creation and device registration time.
Signed-off-by: Parav Pandit
---
include/linux/cgroup_rdma.h | 79
include/linux/cgroup_subsys.h | 4 +
init/Kconfig | 11 +
kernel/Makefile | 1 +
kernel/cgroup_rdma.c | 995 ++
5 files changed, 1090 insertions(+)
create mode 100644 include/linux/cgroup_rdma.h
create mode 100644 kernel/cgroup_rdma.c
diff --git a/include/linux/cgroup_rdma.h b/include/linux/cgroup_rdma.h
new file mode 100644
index 000..33f2d37
--- /dev/null
+++ b/include/linux/cgroup_rdma.h
@@ -0,0 +1,79 @@
+#ifndef _CGROUP_RDMA_H
+#define _CGROUP_RDMA_H
+
+#include
+#include
+
+/*
+ * This file is subject to the terms and conditions of version 2 of the GNU
+ * General Public License. See the file COPYING in the main directory of the
+ * Linux distribution for more details.
+ */
+
+enum rdmacg_resource_pool_type {
+ RDMACG_RESOURCE_POOL_VERB,
+ RDMACG_RESOURCE_POOL_HW,
+ RDMACG_RESOURCE_POOL_TYPE_MAX,
+};
+
+struct rdma_cgroup {
+#ifdef CONFIG_CGROUP_RDMA
+ struct cgroup_subsys_state css;
+
+ spinlock_t rpool_list_lock; /* protects resource pool list */
+ struct list_head rpool_head;/* head to keep track of all resource
+* pools that belongs to this cgroup.
+*/
+#endif
+};
+
+#ifdef CONFIG_CGROUP_RDMA
+
+struct rdmacg_device;
+
+struct rdmacg_pool_info {
+ struct match_token *resource_table;
+ int resource_count;
+};
+
+struct rdmacg_resource_pool_ops {
+ struct rdmacg_pool_info*
+ (*get_resource_pool_tokens)(struct rdmacg_device *);
+};
+
+struct rdmacg_device {
+ struct rdmacg_resource_pool_ops
+ *rpool_ops[RDMACG_RESOURCE_POOL_TYPE_MAX];
+ struct list_headrdmacg_list;
+ char*name;
+};
+
+/* APIs for RDMA/IB stack to publish when a device wants to
+ * participate in resource accounting
+ */
+void rdmacg_register_device(struct rdmacg_device *device, char *dev_name);
+void rdmacg_unregister_device(struct rdmacg_device *device);
+
+/* APIs for RDMA/IB stack to charge/uncharge pool specific resources */
+int rdmacg_try_charge(struct rdma_cgroup **rdmacg,
+ struct rdmacg_device *device,
+ enum rdmacg_resource_pool_type type,
+ int resource_index,
+ int num);
+void rdmacg_uncharge(struct rdma_cgroup *cg,
+struct rdmacg_device *device,
+enum rdmacg_resource_pool_type type,
+int resource_index,
+int num);
+
+void rdmacg_set_rpool_ops(struct rdmacg_device *device,
+ enum rdmacg_resource_pool_type pool_type,
+ struct rdmacg_resource_pool_ops *ops);
+void rdmacg_clear_rpool_ops(struct rdmacg_device *device,
+ enum rdmacg_resource_pool_type pool_type);
+int rdmacg_query_limit(struct rdmacg_device *device,
+ enum rdmacg_resource_pool_type type,
+ int *limits, int max_count);
+
+#endif /* CONFIG_CGROUP_RDMA */
+#endif /* _CGROUP_RDMA_H */
diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index 0df0336a..d0e597c 100644
---
[PATCHv4 2/3] IB/core: added support to use rdma cgroup controller
Added support APIs for IB core to register/unregister every RDMA device
with rdma cgroup for tracking verbs and hw resources.
IB core registers with rdma cgroup controller and also defines resources
that can be accounted.
Added support APIs for uverbs layer to make use of rdma controller.
Added uverbs layer to perform resource charge/uncharge functionality.
Signed-off-by: Parav Pandit
---
drivers/infiniband/core/Makefile | 1 +
drivers/infiniband/core/cgroup.c | 137 ++
drivers/infiniband/core/core_priv.h | 45
drivers/infiniband/core/device.c | 8 ++
drivers/infiniband/core/uverbs_cmd.c | 209 +++---
drivers/infiniband/core/uverbs_main.c | 28 +
include/rdma/ib_verbs.h | 27 -
7 files changed, 439 insertions(+), 16 deletions(-)
create mode 100644 drivers/infiniband/core/cgroup.c
diff --git a/drivers/infiniband/core/Makefile b/drivers/infiniband/core/Makefile
index d43a899..df40cee 100644
--- a/drivers/infiniband/core/Makefile
+++ b/drivers/infiniband/core/Makefile
@@ -13,6 +13,7 @@ ib_core-y := packer.o ud_header.o verbs.o
sysfs.o \
roce_gid_mgmt.o
ib_core-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
ib_core-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o umem_rbtree.o
+ib_core-$(CONFIG_CGROUP_RDMA) += cgroup.o
ib_mad-y :=mad.o smi.o agent.o mad_rmpp.o
diff --git a/drivers/infiniband/core/cgroup.c b/drivers/infiniband/core/cgroup.c
new file mode 100644
index 000..230b048
--- /dev/null
+++ b/drivers/infiniband/core/cgroup.c
@@ -0,0 +1,137 @@
+/*
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include
+#include
+
+#include "core_priv.h"
+
+/**
+ * resource table definition as to be seen by the user.
+ * Need to add entries to it when more resources are
+ * added/defined at IB verb/core layer.
+ */
+static match_table_t resource_tokens = {
+ {RDMA_VERB_RESOURCE_UCTX, "uctx=%d"},
+ {RDMA_VERB_RESOURCE_AH, "ah=%d"},
+ {RDMA_VERB_RESOURCE_PD, "pd=%d"},
+ {RDMA_VERB_RESOURCE_CQ, "cq=%d"},
+ {RDMA_VERB_RESOURCE_MR, "mr=%d"},
+ {RDMA_VERB_RESOURCE_MW, "mw=%d"},
+ {RDMA_VERB_RESOURCE_SRQ, "srq=%d"},
+ {RDMA_VERB_RESOURCE_QP, "qp=%d"},
+ {RDMA_VERB_RESOURCE_FLOW, "flow=%d"},
+ {-1, NULL}
+};
+
+/**
+ * setup table pointers for RDMA cgroup to access.
+ */
+static struct rdmacg_pool_info verbs_token_info = {
+ .resource_table = resource_tokens,
+ .resource_count =
+ (sizeof(resource_tokens) / sizeof(struct match_token)) - 1,
+};
+
+static struct rdmacg_pool_info*
+ rdmacg_get_resource_pool_tokens(struct rdmacg_device *device)
+{
+ return _token_info;
+}
+
+static struct rdmacg_resource_pool_ops verbs_pool_ops = {
+ .get_resource_pool_tokens = _get_resource_pool_tokens,
+};
+
+/**
+ * ib_device_register_rdmacg - register with rdma cgroup.
+ * @device: device to register to participate in resource
+ * accounting by rdma cgroup.
+ *
+ * Register with the rdma cgroup. Should be called before
+ * exposing rdma device to user space applications to avoid
+ * resource accounting leak.
+ * HCA drivers should set resource pool ops first if they wish
+ * to support hw specific resource accounting before IB core
+ * registers with rdma cgroup.
+ */
+void ib_device_register_rdmacg(struct ib_device *device)
+{
+ rdmacg_set_rpool_ops(>cg_device,
+RDMACG_RESOURCE_POOL_VERB,
+_pool_ops);
+ rdmacg_register_device(>cg_device, device->name);
+}
+
+/**
+
[PATCHv4 0/3] rdmacg: IB/core: rdma controller support
This patchset adds support for RDMA cgroup by addressing review comments of [2], [1] and by implementing published RFC [3]. Overview: Currently user space applications can easily take away all the rdma device specific resources such as AH, CQ, QP, MR etc. Due to which other applications in other cgroup or kernel space ULPs may not even get chance to allocate any rdma resources. This results into service unavailibility. RDMA cgroup addresses this issue by allowing resource accounting, limit enforcement on per cgroup, per rdma device basis. Resources are not defined by the RDMA cgroup. Resources are defined by RDMA/IB stack & optionally by HCA vendor device drivers. This allows rdma cgroup to remain constant while RDMA/IB stack can evolve without the need of rdma cgroup update. A new resource can be easily added by the RDMA/IB stack without touching rdma cgroup. RDMA uverbs layer will enforce limits on well defined RDMA verb resources without any HCA vendor device driver involvement. RDMA uverbs layer will not do accounting of hw vendor specific resources. Instead rdma cgroup provides set of APIs through which vendor specific drivers can define their own resources (upto 64) that can be accounted by rdma cgroup. Resource limit enforcement is hierarchical. When process is migrated with active RDMA resources, rdma cgroup continues to uncharge original cgroup for allocated resource. New resource is charged to current process's cgroup, which means if the process is migrated with active resources, for new resources it will be charged to new cgroup and old resources will be correctly uncharged from old cgroup. Changes from v3: * (To address comments from Tejun) 1. Renamed cg_resource to rdmacg_resource 2. Merged dealloc_cg_rpool and _dealloc_cg_rpool to single function 3. Renamed _find_cg_rpool to find_cg_rpool_locked() 5. Removed RDMACG_MAX_RESOURCE_INDEX limitation 6. Fixed few alignments. 7. Improved description for RDMA cgroup configuration menu 8. Renamed cg_list_lock to rpool_list_lock to reflect the lock is for rpools. 9. Renamed _get_cg_rpool to find_cg_rpool. 10. Made creator as int variable, instead of atomic as its not required to be atomic. * Fixed freeing right rpool during query_limit error path * Added copywrite for cgroup.c * Removed including parser.h from cgroup.c as its included by cgroup_rdma.h * Reduced try_charge functions to single function and removed duplicate comments. Changes from v2: * Fixed compilation error reported by 0-DAY kernel test infrastructure for m68k architecture where CONFIG_CGROUP is also not defined. * Fixed comment in patch to refer to legacy mode of cgroup, changed to refer to v1 and v2 version. * Added more information in commit log for rdma controller patch. Changes from v1: * (To address comments from Tejun) a. reduces 3 patches to single patch b. removed resource word from the cgroup configuration files c. changed cgroup configuration file names to match other cgroups d. removed .list file and merged functionality with .max file * Based on comment to merge to single patch for rdma controller; IB/core patches are reduced to single patch. * Removed pid cgroup map and simplified design - Charge/Uncharge caller stack keeps track of the rdmacg for given resource. This removes the need to maintain and perform hash lookup. This also allows little more accurate resource charging/uncharging when process moved from one to other cgroup with active resources and continue to allocate more. * Critical fix: Removed rdma cgroup's dependency on the kernel module header files to avoid crashes when modules are upgraded without kernel upgrade, which is very common due to high amount of changes in IB stack and it is also shipped as individual kernel modules. * uboject extended to keep track of the owner rdma cgroup, so that same rdmacg can be used while uncharging. * Added support functions to hide details of rdmacg device in uverbs modules for cases of cgroup enabled/disabled at compile time. This avoids multiple ifdefs for every API in uverbs layer. * Removed failure counters in first patch, which will be added once initial feature is merged. * Fixed stale rpool access which is getting freed, while doing configuration to rdma.verb.max file. * Fixed rpool resource leak while querying max, current values. Changes from v0: (To address comments from Haggai, Doug, Liran, Tejun, Sean, Jason) * Redesigned to support per device per cgroup limit settings by bringing concept of resource pool. * Redesigned to let IB stack define the resources instead of rdma controller using resource template. * Redesigned to support hw vendor specific limits setting (optional to drivers). * Created new rdma controller instead of piggyback on device cgroup. * Fixed race conditions for multiple tasks sharing rdma resources. * Removed dependency on the task_struct.
Re: N900 sleep mode (in 4.5-rc0, if that matters)
Hi!
> > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072
> > > > 000d 48004a28 (fa004a28) cm_idlest3_core
> > > >
> > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems
> > > > constant.
> > >
> > > For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5
> > > blocking which is for OTG and it's PHY. That's a known issue with
> > > musb and setting pm_runtime_irq_safe() on the MUSB parent.
> > >
> > > If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will
> > > start going off assuming the McSPI bit goes low with WLAN idling.
> >
> > Ok, so I tried to compile kernel without omap2430/phy-twl4030usb
> > . That did not help. So I thought, ok, maybe rmmod is needed to
> > trigger some powersaving? But that is not exactly easy to do:
> >
> > pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/omap2430.ko
> > pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/phy-twl4030-usb.ko
> > pavel@n900:/my/tui/ofone$ sudo rmmod phy-twl4030-usb.ko
> > Error: Module phy_twl4030_usb is in use
> > pavel@n900:/my/tui/ofone$
> >
> > Any ideas what jumps to use the modules? Charger code?
>
> I tried a kernel without charger code, and no luck, rmmod fails the
> same way. dmesg says:
> [ 111.093078] wlan0: authenticated
> [ 111.097442] wlan0: associate with 06:27:22:f9:10:6a (try 1/3)
> [ 111.104553] wlan0: RX AssocResp from 06:27:22:f9:10:6a (capab=0x421
> status=0 aid=2)
> [ 111.104705] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2),
> will use 2
> [ 111.104736] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 3),
> will use 2
> [ 111.256652] wlan0: associated
> [ 184.681427] HS USB OTG: no transceiver configured
> [ 184.681488] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
> with status -517
> [ 184.681976] HS USB OTG: no transceiver configured
> [ 184.682006] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
> with status -517
> [ 187.690338] twl4030_usb 4807.i2c:twl@48:twl4030-usb:
> Initialized TWL4030 USB module
> [ 187.698303] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk
> combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
> [ 187.698333] musb-hdrc: MHDRC RTL version 1.400
> [ 187.698333] musb-hdrc: setup fifo_mode 4
> [ 187.698394] musb-hdrc: 28/31 max ep, 16384/16384 memory
> pavel@n900:/my/tui/ofone$
I added following hack to phy-twl4030-usb.c so that I could avoid
modules and module unloading problem. But still could not get it to
sleep :-(.
Pavel
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 3a707dd..ac3761b 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -532,6 +532,43 @@ static ssize_t twl4030_usb_vbus_show(struct device *dev,
}
static DEVICE_ATTR(vbus, 0444, twl4030_usb_vbus_show, NULL);
+static ssize_t twl4030_test_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(dev);
+ int ret = -EINVAL;
+
+ mutex_lock(>lock);
+ ret = sprintf(buf, "%s\n", "hello, world");
+ mutex_unlock(>lock);
+
+ return ret;
+}
+
+static int twl4030_shutdown(struct twl4030_usb *twl);
+
+static ssize_t twl4030_test_store(struct device *dev,
+struct device_attribute *attr, const char *buf, size_t count)
+{
+ unsigned long tmp;
+
+ struct twl4030_usb *twl = dev_get_drvdata(dev);
+
+ mutex_lock(>lock);
+ sscanf(buf, "%lX", );
+ printk("TWL HACK: tmp = 0x%lX\n", tmp);
+ mutex_unlock(>lock);
+
+ if (tmp == 0xdead) {
+ printk("TWL HACK: killing hardware\n");
+ printk("TWL HACK: killing hardware = %d\n",
twl4030_shutdown(twl));
+ }
+
+ return strnlen(buf, count);
+}
+
+static DEVICE_ATTR(test, 0664, twl4030_test_show, twl4030_test_store);
+
static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
{
struct twl4030_usb *twl = _twl;
@@ -710,6 +747,9 @@ static int twl4030_usb_probe(struct platform_device *pdev)
if (device_create_file(>dev, _attr_vbus))
dev_warn(>dev, "could not create sysfs file\n");
+ if (device_create_file(>dev, _attr_test))
+ dev_warn(>dev, "could not create sysfs file #2\n");
+
ATOMIC_INIT_NOTIFIER_HEAD(>phy.notifier);
pm_runtime_use_autosuspend(>dev);
@@ -745,14 +785,12 @@ static int twl4030_usb_probe(struct platform_device *pdev)
return 0;
}
-static int twl4030_usb_remove(struct platform_device *pdev)
+static int twl4030_shutdown(struct twl4030_usb *twl)
{
- struct twl4030_usb *twl = platform_get_drvdata(pdev);
int val;
pm_runtime_get_sync(twl->dev);
cancel_delayed_work(>id_workaround_work);
- device_remove_file(twl->dev, _attr_vbus);
Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver
On Fri, Jan 29, 2016 at 2:38 PM, Timur Tabi wrote: > Rob Herring wrote: [...] Isn't this a user enabled feature if the h/w supports it? >>> >>> >>> >>> Is there a sysfs entry for that? We were planning on having a similar >>> ACPI >>> property. >> >> >> It would be in ethtool I think. > > > Ah, this driver does not support ethtool yet. > > However, based on a cursory look of ethtool, it appears that there's only an > option to query the current timestamp, but not actually enable/disable the > feature. The e1000e driver, for example, just forces the feature by default > for various chips. Is there any reason why we shouldn't enable it if the > hardware supports it? Probably not. You simply ignore the timestamp if you don't care. So then why do you want a DT property? Rob
Re: [PATCH net-next] netfilter: nf_conntrack: remove the unneed check for *bucket
Weidong Wang wrote:
> In the 'for(...) {}', the *bucket alwasy < net->ct.htable_size,
> so remove the check
> @@ -1383,14 +1383,12 @@ get_next_corpse(struct net *net, int (*iter)(struct
> nf_conn *i, void *data),
> lockp = _conntrack_locks[*bucket % CONNTRACK_LOCKS];
> local_bh_disable();
> spin_lock(lockp);
> - if (*bucket < net->ct.htable_size) {
AFAIU net->ct.htable_size can shrink between for-test and aquiring
the bucket lockp, so this additional if-test is needed.
Re: [tip:x86/asm] x86/syscalls: Remove __SYSCALL_COMMON and __SYSCALL_X32
On January 30, 2016 9:35:57 AM PST, Andy Lutomirski wrote: >On Sat, Jan 30, 2016 at 1:31 AM, Ingo Molnar wrote: >> >> * Andy Lutomirski wrote: >> >>> >>>+ if [ "$abi" == "COMMON" -o "$abi" == "64" ]; then >>> >>>+ # COMMON is the same as 64, except that we don't >expect X32 >>> >>>+ # programs to use it. Our expectation has nothing to >do with >>> >>>+ # any generated code, so treat them the same. >>> >>>+ emit 64 "$nr" "$entry" "$compat" >>> >>>+ elif [ "$abi" == "X32" ]; then >>> >>>+ # X32 is equivalent to 64 on an X32-compatible kernel. >>> >>>+ echo "#ifdef CONFIG_X86_X32_ABI" >>> >>>+ emit 64 "$nr" "$entry" "$compat" >>> >>>+ echo "#endif" >>> >>>+ elif [ "$abi" == "I386" ]; then >>> >>>+ emit "$abi" "$nr" "$entry" "$compat" >>> >>>+ else >>> >>>+ echo "Unknown abi $abi" >&2 >>> >>>+ exit 1 >>> >>>+ fi >> >>> No combinatorial explosion, please. We could use __SYSCALL(nr, sym, >>> abi, qual), though. >> >> Mind fixing it, so that we get back the arch-neutral property? >> > >I need some guidance as to the goal to do a good job. > >In the version in -tip, I have this thing: > >if [ "$abi" == "64" -a -n "$compat" ]; then >echo "a compat entry for a 64-bit syscall makes no sense" >&2 >exit 1 >fi > >Moving that outside the script will either be impossible or an >exercise in really awful C preprocessor hacks. We could keep that >under the theory that it's arch-neutral. > >It might be nice to add a similar warning that a compat entry for an >x32 syscall makes so sense. That's a little less arch-neutral, >although it wouldn't be actively harmful on any architecture, since >"x32" wouldn't occur in the first place. > >Other than that, I could add a little header called >syscall_abi_mapping.h containing something like: > >#ifndef __SYSCALL_ABI_MAPPING_H >#define __SYSCALL_ABI_MAPPING_H > >#ifdef CONFIG_X86_32 > >/* Only I386 entries should ever be compiled into 32-bit kernels. */ >#define __SYSCALL_ABI_I386(nr, entry, qual, compat, compat_qual) >__SYSCALL_I386(nr, entry, qual) > >#else > >/* I386 entries on 64-bit kernels use the compat entry point. */ >#define __SYSCALL_ABI_I386(nr, entry, qual, compat, compat_qual) >__SYSCALL_I386(nr, compat, compat_qual) > >#define __SYSCALL_ABI_common(nr, entry, compat, qual) >#define __SYSCALL_ABI_64(nr, entry, qual, compat, compat_qual) >__SYSCALL_64(nr, entry, qual) >#ifdef CONFIG_X86_X32 >#define __SYSCALL_ABI_x32(nr, entry, qual, compat, compat_qual) >__SYSCALL_64(nr, entry, qual) >#else >#define __SYSCALL_ABI_x32(nr, entry, qual, compat, compat_qual) >__SYSCALL_64(nr, entry, qual) >#endif > >#endif > >#endif > >and teach syscalltbl.sh to emit #include >at the beginning of syscalls_32.h and syscalls_64.h and to reference >those macros. > >hpa, would that meet your requirements? > >IMO this is quite a bit messier than the code in -tip, and I'm >honestly not convinced it's an improvement. > >--Andy Something like that... however, I can't look at in detail right now. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
Re: [PATCH 1/1] broken perf tool on 4.4-rc1
It’s v4.5-rc1, not 4.4-rc1. never mind the version in the title.
Re: [PATCH v9 04/13] task_isolation: add initial support
On Fri, Jan 29, 2016 at 01:18:05PM -0500, Chris Metcalf wrote:
> On 01/27/2016 07:28 PM, Frederic Weisbecker wrote:
> >On Tue, Jan 19, 2016 at 03:45:04PM -0500, Chris Metcalf wrote:
> >>You asked what happens if nohz_full= is given as well, which is a very
> >>good question. Perhaps the right answer is to have an early_initcall
> >>that suppresses task isolation on any cores that lost their nohz_full
> >>or isolcpus status due to later boot command line arguments (and
> >>generate a console warning, obviously).
> >I'd rather imagine that the final nohz full cpumask is "nohz_full=" |
> >"task_isolation="
> >That's the easiest way to deal with and both nohz and task isolation can call
> >a common initializer that takes care of the allocation and add the cpus to
> >the mask.
>
> I like it!
>
> And by the same token, the final isolcpus cpumask is "isolcpus=" |
> "task_isolation="?
> That seems like we'd want to do it to keep things parallel.
We have reverted the patch that made isolcpus |= nohz_full. Too
many people complained about unusable machines with NO_HZ_FULL_ALL
But the user can still set that parameter manually.
>
> +bool _task_isolation_ready(void)
> +{
> + WARN_ON_ONCE(!irqs_disabled());
> +
> + /* If we need to drain the LRU cache, we're not ready. */
> + if (lru_add_drain_needed(smp_processor_id()))
> + return false;
> +
> + /* If vmstats need updating, we're not ready. */
> + if (!vmstat_idle())
> + return false;
> +
> + /* Request rescheduling unless we are in full dynticks mode. */
> + if (!tick_nohz_tick_stopped()) {
> + set_tsk_need_resched(current);
> >>>I'm not sure doing this will help getting the tick to get stopped.
> >>Well, I don't know that there is anything else we CAN do, right? If there's
> >>another task that can run, great - it may be that that's why full dynticks
> >>isn't happening yet. Or, it might be that we're waiting for an RCU tick and
> >>there's nothing else we can do, in which case we basically spend our time
> >>going around through the scheduler code and back out to the
> >>task_isolation_ready() test, but again, there's really nothing else more
> >>useful we can be doing at this point. Once the RCU tick fires (or whatever
> >>it was that was preventing full dynticks from engaging), we will pass this
> >>test and return to user space.
> >There is nothing at all you can do and setting TIF_RESCHED won't help either.
> >If there is another task that can run, the scheduler takes care of resched
> >by itself :-)
>
> The problem is that the scheduler will only take care of resched at a
> later time, typically when we get a timer interrupt later.
When a task is enqueued, the scheduler sets TIF_RESCHED on the target. If the
target is remote it sends an IPI, if it's local then we wait the next reschedule
point (preemption points, voluntary reschedule, interrupts). There is just
nothing
you can do to accelerate that.
> By invoking the scheduler here, we allow any tasks that are ready to run to
> run
> immediately, rather than waiting for an interrupt to wake the scheduler.
Well, in this case here we are interested in the current CPU. And if a task
got awoken and waits for the current CPU, it will have an opportunity to get
schedule on syscall exit.
> Plenty of places in the kernel just call schedule() directly when they are
> waiting. Since we're waiting here regardless, we might as well
> immediately get any other runnable tasks dealt with.
>
> We could also just return "false" in _task_isolation_ready(), and then
> check tick_nohz_tick_stopped() in _task_isolation_enter() and if false,
> call schedule() explicitly there, but that seems a little more roundabout.
> Admittedly it's more usual to see kernel code call schedule() directly
> to yield the processor, but in this case I'm not convinced it's cleaner
> given we're already in a loop where the caller is checking TIF_RESCHED
> and then calling schedule() when it's set.
You could call cond_resched(), but really syscall exit is enough for what
you want. And the problem here if a task prevents the CPU from stopping the
tick is that task itself, not the fact it doesn't get scheduled. If we have
other tasks than the current isolated one on the CPU, it means that the
environment is not ready for hard isolation.
And in general: we shouldn't loop at all there: if something depends on the
tick,
the CPU is not ready for isolation and something needs to be done: setting
some task affinity, etc... So we should just fail the prctl and let the user
deal with it.
>
> --
> Chris Metcalf, EZChip Semiconductor
> http://www.ezchip.com
>
[PATCH 1/1] broken perf tool on 4.4-rc1
reproduce:
lzto@objd ~ $ ~/linux/tools/perf/perf record -I -e
intel_pt/tsc=1,noretcomp=1/u /bin/ls
lzto@objd ~ $ ~/linux/tools/perf/perf script -F
event,comm,pid,tid,time,addr,ip,sym,dso,iregs
Segmentation fault
lzto@objd ~ $
Upon further investigation, it seems that
commit 747a9b0a08ae ("Merge branch 'perf-urgent-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
breaks perf tool.
__list_del(): tools/include/linux/list.h does not check null pointer dereference
Signed-off-by: Tong Zhang
---
tools/include/linux/list.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/include/linux/list.h b/tools/include/linux/list.h
index 1da4238..1d644a0 100644
--- a/tools/include/linux/list.h
+++ b/tools/include/linux/list.h
@@ -85,8 +85,10 @@ static inline void list_add_tail(struct list_head *new,
struct list_head *head)
*/
static inline void __list_del(struct list_head * prev, struct list_head * next)
{
- next->prev = prev;
- WRITE_ONCE(prev->next, next);
+ if (next)
+ next->prev = prev;
+ if (prev)
+ WRITE_ONCE(prev->next, next);
}
/**
--
2.4.10
[PATCH 1/1] broken perf tool on 4.4-rc1
reproduce:
lzto@objd ~ $ ~/linux/tools/perf/perf record -I -e
intel_pt/tsc=1,noretcomp=1/u /bin/ls
lzto@objd ~ $ ~/linux/tools/perf/perf script -F
event,comm,pid,tid,time,addr,ip,sym,dso,iregs
Segmentation fault
lzto@objd ~ $
Upon further investigation, it seems that
commit 747a9b0a08ae ("Merge branch 'perf-urgent-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
breaks perf tool.
__list_del(): tools/include/linux/list.h does not check null pointer dereference
Signed-off-by: Tong Zhang
---
tools/include/linux/list.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/include/linux/list.h b/tools/include/linux/list.h
index 1da4238..1d644a0 100644
--- a/tools/include/linux/list.h
+++ b/tools/include/linux/list.h
@@ -85,8 +85,10 @@ static inline void list_add_tail(struct list_head *new,
struct list_head *head)
*/
static inline void __list_del(struct list_head * prev, struct list_head * next)
{
- next->prev = prev;
- WRITE_ONCE(prev->next, next);
+ if (next)
+ next->prev = prev;
+ if (prev)
+ WRITE_ONCE(prev->next, next);
}
/**
--
2.4.10
Re: [PATCH net v2 1/4] net/core: relax BUILD_BUG_ON in netdev_stats_to_stats64
On Sat, Jan 30, 2016 at 03:39:01PM -0500, Jarod Wilson wrote:
> On Sat, Jan 30, 2016 at 10:34:32AM -0800, Eric Dumazet wrote:
> > On Sat, 2016-01-30 at 13:19 -0500, Jarod Wilson wrote:
> > > The netdev_stats_to_stats64 function copies the deprecated
> > > net_device_stats format stats into rtnl_link_stats64 for legacy support
> > > purposes, but with the BUILD_BUG_ON as it was, it wasn't possible to
> > > extend rtnl_link_stats64 without also extending net_device_stats. Relax
> > > the BUILD_BUG_ON to only require that rtnl_link_stats64 is larger, and
> > > zero out all the stat counters that aren't present in net_device_stats.
> > >
> > > CC: Eric Dumazet
> > > CC: net...@vger.kernel.org
> > > Signed-off-by: Jarod Wilson
> > > ---
> > > Re-re-sending, hopefully getting the patch to the right list this time.
> > >
> > > net/core/dev.c | 13 +
> > > 1 file changed, 9 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > index 8cba3d8..575a7df 100644
> > > --- a/net/core/dev.c
> > > +++ b/net/core/dev.c
> > > @@ -7253,25 +7253,30 @@ void netdev_run_todo(void)
> > > }
> > > }
> > >
> > > -/* Convert net_device_stats to rtnl_link_stats64. They have the same
> > > - * fields in the same order, with only the type differing.
> > > +/* Convert net_device_stats to rtnl_link_stats64. rtnl_link_stats64 has
> > > + * all the same fields in the same order as net_device_stats, with only
> > > + * the type differing, but rtnl_link_stats64 may have additional fields
> > > + * at the end for newer counters.
> > > */
> > > void netdev_stats_to_stats64(struct rtnl_link_stats64 *stats64,
> > >const struct net_device_stats *netdev_stats)
> > > {
> > > #if BITS_PER_LONG == 64
> > > - BUILD_BUG_ON(sizeof(*stats64) != sizeof(*netdev_stats));
> > > + BUILD_BUG_ON(sizeof(*stats64) < sizeof(*netdev_stats));
> > > memcpy(stats64, netdev_stats, sizeof(*stats64));
> > > #else
> > > size_t i, n = sizeof(*stats64) / sizeof(u64);
> > > const unsigned long *src = (const unsigned long *)netdev_stats;
> > > u64 *dst = (u64 *)stats64;
> > >
> > > - BUILD_BUG_ON(sizeof(*netdev_stats) / sizeof(unsigned long) !=
> > > + BUILD_BUG_ON(sizeof(*netdev_stats) / sizeof(unsigned long) >
> > >sizeof(*stats64) / sizeof(u64));
> > > for (i = 0; i < n; i++)
> > > dst[i] = src[i];
> > > #endif
> > > + /* zero out counters that only exist in rtnl_link_stats64 */
> > > + memset((char *)stats64 + sizeof(*netdev_stats), 0,
> > > +sizeof(*stats64) - sizeof(*netdev_stats));
> >
> > Are you sure it works on 32bit arches ?
>
> Ew, no, it won't work correctly on 32-bit. The for loop is going to copy
> data into dst from beyond the end of netdev_stats, and the range looks
> like it won't be right either, only half of the added stats64 space will
> get zeroed out. Okay, I'll fix that up correctly.
Completely untested as of yet, but I think something like the following
looks correct. I'll give it a spin as soon as I can.
diff --git a/net/core/dev.c b/net/core/dev.c
index 8cba3d8..65863e5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7253,24 +7253,31 @@ void netdev_run_todo(void)
}
}
-/* Convert net_device_stats to rtnl_link_stats64. They have the same
- * fields in the same order, with only the type differing.
+/* Convert net_device_stats to rtnl_link_stats64. rtnl_link_stats64 has
+ * all the same fields in the same order as net_device_stats, with only
+ * the type differing, but rtnl_link_stats64 may have additional fields
+ * at the end for newer counters.
*/
void netdev_stats_to_stats64(struct rtnl_link_stats64 *stats64,
const struct net_device_stats *netdev_stats)
{
#if BITS_PER_LONG == 64
- BUILD_BUG_ON(sizeof(*stats64) != sizeof(*netdev_stats));
+ BUILD_BUG_ON(sizeof(*stats64) < sizeof(*netdev_stats));
memcpy(stats64, netdev_stats, sizeof(*stats64));
+ /* zero out counters that only exist in rtnl_link_stats64 */
+ memset((char *)stats64 + sizeof(*netdev_stats), 0,
+ sizeof(*stats64) - sizeof(*netdev_stats));
#else
- size_t i, n = sizeof(*stats64) / sizeof(u64);
+ size_t i, n = sizeof(*netdev_stats) / sizeof(unsigned long);
const unsigned long *src = (const unsigned long *)netdev_stats;
u64 *dst = (u64 *)stats64;
- BUILD_BUG_ON(sizeof(*netdev_stats) / sizeof(unsigned long) !=
-sizeof(*stats64) / sizeof(u64));
+ BUILD_BUG_ON(n > sizeof(*stats64) / sizeof(u64));
for (i = 0; i < n; i++)
dst[i] = src[i];
+ /* zero out counters that only exist in rtnl_link_stats64 */
+ memset((char *)stats64 + n * sizeof(u64), 0,
+ sizeof(*stats64) - n * sizeof(u64));
#endif
}
EXPORT_SYMBOL(netdev_stats_to_stats64);
--
Jarod Wilson
ja...@redhat.com
[PATCH] Staging: clocking-wizard: CHECK:Please use a blank line
This patch fixes the checkpatch.pl issue:
CHECK: Please use a blank line after function/struct/union/enum declarations
Signed-off-by: SirnamSwetha
---
drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
index 72c79aa..7b8be52 100644
--- a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
+++ b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
@@ -71,6 +71,7 @@ struct clk_wzrd {
int speed_grade;
bool suspended;
};
+
#define to_clk_wzrd(_nb) container_of(_nb, struct clk_wzrd, nb)
/* maximum frequencies for input/output clocks per speed grade */
--
1.9.1
[PATCH] Staging: clocking-wizard: Avoid CamelCase
This patch fixes the checkpatch.pl issue: CHECK: Avoid CamelCase: CHECK: Avoid CamelCase: Signed-off-by: SirnamSwetha --- drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c index b8e2f61..72c79aa 100644 --- a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c +++ b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c @@ -32,8 +32,8 @@ #define WZRD_CLK_CFG_REG(n)(0x200 + 4 * (n)) -#define WZRD_CLkOUT0_FRAC_EN BIT(18) -#define WZRD_CLkFBOUT_FRAC_EN BIT(26) +#define WZRD_CLKOUT0_FRAC_EN BIT(18) +#define WZRD_CLKFBOUT_FRAC_EN BIT(26) #define WZRD_CLKFBOUT_MULT_SHIFT 8 #define WZRD_CLKFBOUT_MULT_MASK(0xff << WZRD_CLKFBOUT_MULT_SHIFT) @@ -195,9 +195,9 @@ static int clk_wzrd_probe(struct platform_device *pdev) /* we don't support fractional div/mul yet */ reg = readl(clk_wzrd->base + WZRD_CLK_CFG_REG(0)) & - WZRD_CLkFBOUT_FRAC_EN; + WZRD_CLKFBOUT_FRAC_EN; reg |= readl(clk_wzrd->base + WZRD_CLK_CFG_REG(2)) & -WZRD_CLkOUT0_FRAC_EN; +WZRD_CLKOUT0_FRAC_EN; if (reg) dev_warn(>dev, "fractional div/mul not supported\n"); -- 1.9.1
Re: [PATCHv3 1/3] rdmacg: Added rdma cgroup controller.
Hi Tejun,
On Sun, Jan 31, 2016 at 12:00 AM, Tejun Heo wrote:
> Hello,
>
> On Sat, Jan 30, 2016 at 08:53:05PM +0530, Parav Pandit wrote:
>> +#ifdef CONFIG_CGROUP_RDMA
>> +#define RDMACG_MAX_RESOURCE_INDEX (64)
>
> The list of resources are known at compile time. Why is this separate
> fixed number necessary?
>
Its not necessary. It was carry forwarded from older design. I will
remove in v4.
>> +struct match_token;
>
> There's no circular dependency issue here. Include the appropriate
> header.
o.k. I will fix it.
>
>> +struct rdmacg_device;
>> +
>> +struct rdmacg_pool_info {
>> + struct match_token *resource_table;
>> + int resource_count;
>> +};
>> +
>> +struct rdmacg_resource_pool_ops {
>> + struct rdmacg_pool_info*
>> + (*get_resource_pool_tokens)(struct rdmacg_device *);
>> +};
>
> Why does it need external op table? The types of resources are gonna
> be fixed at compile time.
IB modules are kernel loadable modules which are defining the resource.
So array size and their names are not defined at compile time of rdma
cgroup code.
Kernel code also cannot depend on loadable module file either via
inclusion as that in v2 patch.
That leads to crash when loadable modules are upgraded.
V1 patch had IB resources defined in the header file of rdmacg, which
I believe is very restrictive model with evolving rdma stack and
features.
Therefore it will be kept as defined in v3 patch in IB headers (non
compile time for rdma cgroup). So support infrastructure APIs will
continue.
> The only thing necessary is each device
> declaring which resources are to be used.
>
Thats what rpool_ops structure does, allowing to query name strings
and type of it by utilizing the match tokens.
>> +struct rdmacg_device {
>> + struct rdmacg_resource_pool_ops
>> + *rpool_ops[RDMACG_RESOURCE_POOL_TYPE_MAX];
>> + struct list_headrdmacg_list;
>> + char*name;
>> +};
>> +
>> +/* APIs for RDMA/IB stack to publish when a device wants to
>> + * participate in resource accounting
>> + */
>
> Please read CodingStyle.
>
Sorry about it. I will add the initial blank line. From driver
background I was avoiding it.
>> +config CGROUP_RDMA
>> + bool "RDMA controller"
>> + help
>> + Provides enforcement of RDMA resources at RDMA/IB verb level and
>> + enforcement of any RDMA/IB capable hardware advertized resources.
> ^?
>> + Its fairly easy for applications to exhaust RDMA resources, which
> ^^^
>> + can result into kernel consumers or other application consumers of
> ^ in ^ just say "consumers"?
>> + RDMA resources left with no resources. RDMA controller is designed
> ^ The sentence doesn't read well.
>> + to stop this from happening.
>> + Attaching existing processes with active RDMA resources to the cgroup
>> + hierarchy will be allowed even if can cross the hierarchy's limit.
> ^?
>
Fixed them. Please review them in next patch.
>> +#define RDMACG_USR_CMD_REMOVE "remove"
>
> Why is this necessary?
>
User can unset the configured limit by writing "remove" for a given
device, instead of writing max values for all the resources.
As I explained in cover note and other comment, when its marked for
remove, the resource pool is marked as of default type so that it can
be freed. When all resources are freed, we don't free the rpool
because it holds the configured limit.
>> +/* resource tracker per resource for rdma cgroup */
>> +struct cg_resource {
>> + int max;
>> + atomic_t usage;
>> +};
>
> rdmacg_resource? Also, wouldn't it be better to use u64?
>
I will change to rdmacg_resource. As present we have 24-bit wide resources.
64-bit might not needed in near future. If there are inputs comes from
Intel/Mellanox for this I will bump to 64-bit.
Otherwise I prefer to keep it 32-bit.
>> +/**
>> + * pool type indicating either it got created as part of default
>> + * operation or user has configured the group.
>> + * Depends on the creator of the pool, its decided to free up
>> + * later or not.
>> + */
>> +enum rpool_creator {
>> + RDMACG_RPOOL_CREATOR_DEFAULT,
>> + RDMACG_RPOOL_CREATOR_USR,
>> +};
>
> Why does this matter?
As you got in later comment and as I explained above, basically
resource marked as of user type is not freed, until either device goes
away or either user wants to clear the configuration.
>
>> +/**
>> + * resource pool object which represents, per cgroup, per device,
>> + * per resource pool_type resources. There are multiple instance
>> + * of this object per cgroup, therefore it cannot be embedded within
>> + * rdma_cgroup structure. Its maintained as list.
>> + */
>> +struct cg_resource_pool {
>> + struct list_head cg_list;
>> + struct rdmacg_device *device;
>> + enum rdmacg_resource_pool_type type;
>> +
Re: [PATCH net v2 1/4] net/core: relax BUILD_BUG_ON in netdev_stats_to_stats64
On Sat, Jan 30, 2016 at 10:34:32AM -0800, Eric Dumazet wrote:
> On Sat, 2016-01-30 at 13:19 -0500, Jarod Wilson wrote:
> > The netdev_stats_to_stats64 function copies the deprecated
> > net_device_stats format stats into rtnl_link_stats64 for legacy support
> > purposes, but with the BUILD_BUG_ON as it was, it wasn't possible to
> > extend rtnl_link_stats64 without also extending net_device_stats. Relax
> > the BUILD_BUG_ON to only require that rtnl_link_stats64 is larger, and
> > zero out all the stat counters that aren't present in net_device_stats.
> >
> > CC: Eric Dumazet
> > CC: net...@vger.kernel.org
> > Signed-off-by: Jarod Wilson
> > ---
> > Re-re-sending, hopefully getting the patch to the right list this time.
> >
> > net/core/dev.c | 13 +
> > 1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 8cba3d8..575a7df 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -7253,25 +7253,30 @@ void netdev_run_todo(void)
> > }
> > }
> >
> > -/* Convert net_device_stats to rtnl_link_stats64. They have the same
> > - * fields in the same order, with only the type differing.
> > +/* Convert net_device_stats to rtnl_link_stats64. rtnl_link_stats64 has
> > + * all the same fields in the same order as net_device_stats, with only
> > + * the type differing, but rtnl_link_stats64 may have additional fields
> > + * at the end for newer counters.
> > */
> > void netdev_stats_to_stats64(struct rtnl_link_stats64 *stats64,
> > const struct net_device_stats *netdev_stats)
> > {
> > #if BITS_PER_LONG == 64
> > - BUILD_BUG_ON(sizeof(*stats64) != sizeof(*netdev_stats));
> > + BUILD_BUG_ON(sizeof(*stats64) < sizeof(*netdev_stats));
> > memcpy(stats64, netdev_stats, sizeof(*stats64));
> > #else
> > size_t i, n = sizeof(*stats64) / sizeof(u64);
> > const unsigned long *src = (const unsigned long *)netdev_stats;
> > u64 *dst = (u64 *)stats64;
> >
> > - BUILD_BUG_ON(sizeof(*netdev_stats) / sizeof(unsigned long) !=
> > + BUILD_BUG_ON(sizeof(*netdev_stats) / sizeof(unsigned long) >
> > sizeof(*stats64) / sizeof(u64));
> > for (i = 0; i < n; i++)
> > dst[i] = src[i];
> > #endif
> > + /* zero out counters that only exist in rtnl_link_stats64 */
> > + memset((char *)stats64 + sizeof(*netdev_stats), 0,
> > + sizeof(*stats64) - sizeof(*netdev_stats));
>
> Are you sure it works on 32bit arches ?
Ew, no, it won't work correctly on 32-bit. The for loop is going to copy
data into dst from beyond the end of netdev_stats, and the range looks
like it won't be right either, only half of the added stats64 space will
get zeroed out. Okay, I'll fix that up correctly.
--
Jarod Wilson
ja...@redhat.com
Re: [PATCH 2/2] sched,time: call __acct_update_integrals once a jiffy
On Sat, Jan 30, 2016 at 06:53:05PM +0100, Mike Galbraith wrote:
> On Sat, 2016-01-30 at 15:20 +0100, Frederic Weisbecker wrote:
> > On Fri, Jan 29, 2016 at 05:43:28PM -0500, Rik van Riel wrote:
>
> > > Run times for the microbenchmark:
> > >
> > > 4.4 3.8 seconds
> > > 4.5-rc1 3.7 seconds
> > > 4.5-rc1 + first patch 3.3 seconds
> > > 4.5-rc1 + both patches 2.3 seconds
> >
> > Very nice improvement!
>
> Tasty indeed.
>
> When nohz_full CPUs are not isolated, ie are being used as generic
> CPUs, get_nohz_timer_target() is a problem with things like tbench.
So by isolated CPU you mean those part of isolcpus= boot option, right?
>
> tbench 8 with Rik's patches applied:
> nohz_full=empty
> Throughput 3204.69 MB/sec 1.000
> nohz_full=1-3,5-7
> Throughput 1354.99 MB/sec .422 1.000
> nohz_full=1-3,5-7 + club below
> Throughput 2762.22 MB/sec .861 2.038
>
> With Rik's patches and a club, tbench becomes nearly acceptable.
> ---
> include/linux/tick.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/include/linux/tick.h
> +++ b/include/linux/tick.h
> @@ -184,7 +184,7 @@ static inline const struct cpumask *hous
> static inline bool is_housekeeping_cpu(int cpu)
> {
> #ifdef CONFIG_NO_HZ_FULL
> - if (tick_nohz_full_enabled())
> + if (tick_nohz_full_enabled() && runqueue_is_isolated(cpu))
> return cpumask_test_cpu(cpu, housekeeping_mask);
This makes me confused. How forcing timers to CPUs in isolcpus is making
better results?
> #endif
> return true;
Re: sound: deadlock between snd_pcm_oss_write/snd_pcm_oss_mmap
On Sat, Jan 30, 2016 at 9:28 PM, Dmitry Vyukov wrote:
> Hello,
>
> I've got the following deadlock report while running syzkaller fuzzer:
>
> [ INFO: possible circular locking dependency detected ]
> 4.5.0-rc1+ #305 Not tainted
> ---
> syz-executor/14254 is trying to acquire lock:
> (>oss.params_lock){+.+.+.}, at: []
> snd_pcm_oss_change_params+0xd4/0x3540 sound/core/oss/pcm_oss.c:852
>
> but task is already holding lock:
> (>mmap_sem){++}, at: [] vm_mmap_pgoff
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (>mmap_sem){++}:
>[] lock_acquire+0x1dc/0x430
> kernel/locking/lockdep.c:3587
>[] __might_fault+0x141/0x1d0 mm/memory.c:3802
>[< inline >] copy_from_user
> ./arch/x86/include/asm/uaccess.h:714
>[< inline >] snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1376
>[] snd_pcm_oss_write+0x250/0x700
> sound/core/oss/pcm_oss.c:2694
>[] __vfs_write+0x113/0x480 fs/read_write.c:528
>[] vfs_write+0x167/0x4a0 fs/read_write.c:577
>[< inline >] SYSC_write fs/read_write.c:624
>[] SyS_write+0x111/0x220 fs/read_write.c:616
>[] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
>
> -> #0 (>oss.params_lock){+.+.+.}:
>[< inline >] check_prev_add kernel/locking/lockdep.c:1855
>[< inline >] check_prevs_add kernel/locking/lockdep.c:1960
>[< inline >] validate_chain kernel/locking/lockdep.c:2146
>[] __lock_acquire+0x31eb/0x4700
> kernel/locking/lockdep.c:3208
>[] lock_acquire+0x1dc/0x430
> kernel/locking/lockdep.c:3587
>[< inline >] __mutex_lock_common kernel/locking/mutex.c:518
>[] mutex_lock_interruptible_nested+0xbc/0xbe0
> kernel/locking/mutex.c:647
>[] snd_pcm_oss_change_params+0xd4/0x3540
> sound/core/oss/pcm_oss.c:852
>[] snd_pcm_oss_mmap+0x3dd/0x4c0
> sound/core/oss/pcm_oss.c:2807
>[] mmap_region+0x897/0x1010 mm/mmap.c:1624
>[] do_mmap+0x754/0x990 mm/mmap.c:1403
>[< inline >] do_mmap_pgoff include/linux/mm.h:1982
>[] vm_mmap_pgoff+0x15f/0x1b0 mm/util.c:328
>[< inline >] SYSC_mmap_pgoff mm/mmap.c:1453
>[] SyS_mmap_pgoff+0x34a/0x580 mm/mmap.c:1411
>[< inline >] SYSC_mmap arch/x86/kernel/sys_x86_64.c:95
>[] SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:86
>[] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
>CPU0CPU1
>
> lock(>mmap_sem);
>lock(>oss.params_lock);
>lock(>mmap_sem);
> lock(>oss.params_lock);
>
> *** DEADLOCK ***
>
> 1 lock held by syz-executor/14254:
> #0: (>mmap_sem){++}, at: []
> vm_mmap_pgoff+0x12c/0x1b0 mm/util.c:327
>
> stack backtrace:
> CPU: 2 PID: 14254 Comm: syz-executor Not tainted 4.5.0-rc1+ #305
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> 88003214f780 82be11ad 8959ac60
> 8959ac60 89573f60 88003214f7d0 814512a8
> 8800333cdf00 8800333ce742 8800333ce720
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
> [] print_circular_bug+0x288/0x340
> kernel/locking/lockdep.c:1228
> [< inline >] check_prev_add kernel/locking/lockdep.c:1855
> [< inline >] check_prevs_add kernel/locking/lockdep.c:1960
> [< inline >] validate_chain kernel/locking/lockdep.c:2146
> [] __lock_acquire+0x31eb/0x4700
> kernel/locking/lockdep.c:3208
> [] lock_acquire+0x1dc/0x430 kernel/locking/lockdep.c:3587
> [< inline >] __mutex_lock_common kernel/locking/mutex.c:518
> [] mutex_lock_interruptible_nested+0xbc/0xbe0
> kernel/locking/mutex.c:647
> [] snd_pcm_oss_change_params+0xd4/0x3540
> sound/core/oss/pcm_oss.c:852
> [] snd_pcm_oss_mmap+0x3dd/0x4c0
> sound/core/oss/pcm_oss.c:2807
> [] mmap_region+0x897/0x1010 mm/mmap.c:1624
> [] do_mmap+0x754/0x990 mm/mmap.c:1403
> [< inline >] do_mmap_pgoff include/linux/mm.h:1982
> [] vm_mmap_pgoff+0x15f/0x1b0 mm/util.c:328
> [< inline >] SYSC_mmap_pgoff mm/mmap.c:1453
> [] SyS_mmap_pgoff+0x34a/0x580 mm/mmap.c:1411
> [< inline >] SYSC_mmap arch/x86/kernel/sys_x86_64.c:95
> [] SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:86
>
>
> On commit 26cd83670f2f5a3d5b5514a1f7d96567cdb9558b.
Similar for snd_pcm_oss_read:
[ 90.050883] [ INFO: possible circular locking dependency detected ]
[ 90.050883] 4.5.0-rc1+ #305 Not tainted
[ 90.050883] ---
[ 90.050883] syz-executor/11689 is trying to
sound: deadlock between snd_pcm_oss_write/snd_pcm_oss_mmap
Hello,
I've got the following deadlock report while running syzkaller fuzzer:
[ INFO: possible circular locking dependency detected ]
4.5.0-rc1+ #305 Not tainted
---
syz-executor/14254 is trying to acquire lock:
(>oss.params_lock){+.+.+.}, at: []
snd_pcm_oss_change_params+0xd4/0x3540 sound/core/oss/pcm_oss.c:852
but task is already holding lock:
(>mmap_sem){++}, at: [] vm_mmap_pgoff
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (>mmap_sem){++}:
[] lock_acquire+0x1dc/0x430
kernel/locking/lockdep.c:3587
[] __might_fault+0x141/0x1d0 mm/memory.c:3802
[< inline >] copy_from_user ./arch/x86/include/asm/uaccess.h:714
[< inline >] snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1376
[] snd_pcm_oss_write+0x250/0x700
sound/core/oss/pcm_oss.c:2694
[] __vfs_write+0x113/0x480 fs/read_write.c:528
[] vfs_write+0x167/0x4a0 fs/read_write.c:577
[< inline >] SYSC_write fs/read_write.c:624
[] SyS_write+0x111/0x220 fs/read_write.c:616
[] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
-> #0 (>oss.params_lock){+.+.+.}:
[< inline >] check_prev_add kernel/locking/lockdep.c:1855
[< inline >] check_prevs_add kernel/locking/lockdep.c:1960
[< inline >] validate_chain kernel/locking/lockdep.c:2146
[] __lock_acquire+0x31eb/0x4700
kernel/locking/lockdep.c:3208
[] lock_acquire+0x1dc/0x430
kernel/locking/lockdep.c:3587
[< inline >] __mutex_lock_common kernel/locking/mutex.c:518
[] mutex_lock_interruptible_nested+0xbc/0xbe0
kernel/locking/mutex.c:647
[] snd_pcm_oss_change_params+0xd4/0x3540
sound/core/oss/pcm_oss.c:852
[] snd_pcm_oss_mmap+0x3dd/0x4c0
sound/core/oss/pcm_oss.c:2807
[] mmap_region+0x897/0x1010 mm/mmap.c:1624
[] do_mmap+0x754/0x990 mm/mmap.c:1403
[< inline >] do_mmap_pgoff include/linux/mm.h:1982
[] vm_mmap_pgoff+0x15f/0x1b0 mm/util.c:328
[< inline >] SYSC_mmap_pgoff mm/mmap.c:1453
[] SyS_mmap_pgoff+0x34a/0x580 mm/mmap.c:1411
[< inline >] SYSC_mmap arch/x86/kernel/sys_x86_64.c:95
[] SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:86
[] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(>mmap_sem);
lock(>oss.params_lock);
lock(>mmap_sem);
lock(>oss.params_lock);
*** DEADLOCK ***
1 lock held by syz-executor/14254:
#0: (>mmap_sem){++}, at: []
vm_mmap_pgoff+0x12c/0x1b0 mm/util.c:327
stack backtrace:
CPU: 2 PID: 14254 Comm: syz-executor Not tainted 4.5.0-rc1+ #305
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
88003214f780 82be11ad 8959ac60
8959ac60 89573f60 88003214f7d0 814512a8
8800333cdf00 8800333ce742 8800333ce720
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
[] print_circular_bug+0x288/0x340
kernel/locking/lockdep.c:1228
[< inline >] check_prev_add kernel/locking/lockdep.c:1855
[< inline >] check_prevs_add kernel/locking/lockdep.c:1960
[< inline >] validate_chain kernel/locking/lockdep.c:2146
[] __lock_acquire+0x31eb/0x4700 kernel/locking/lockdep.c:3208
[] lock_acquire+0x1dc/0x430 kernel/locking/lockdep.c:3587
[< inline >] __mutex_lock_common kernel/locking/mutex.c:518
[] mutex_lock_interruptible_nested+0xbc/0xbe0
kernel/locking/mutex.c:647
[] snd_pcm_oss_change_params+0xd4/0x3540
sound/core/oss/pcm_oss.c:852
[] snd_pcm_oss_mmap+0x3dd/0x4c0 sound/core/oss/pcm_oss.c:2807
[] mmap_region+0x897/0x1010 mm/mmap.c:1624
[] do_mmap+0x754/0x990 mm/mmap.c:1403
[< inline >] do_mmap_pgoff include/linux/mm.h:1982
[] vm_mmap_pgoff+0x15f/0x1b0 mm/util.c:328
[< inline >] SYSC_mmap_pgoff mm/mmap.c:1453
[] SyS_mmap_pgoff+0x34a/0x580 mm/mmap.c:1411
[< inline >] SYSC_mmap arch/x86/kernel/sys_x86_64.c:95
[] SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:86
On commit 26cd83670f2f5a3d5b5514a1f7d96567cdb9558b.
Re: [PATCH v2] dm pref-path: provides preferred path load balance policy
On Sat, Jan 30, 2016 at 09:32:53AM +0100, Hannes Reinecke wrote:
> On 01/29/2016 06:50 PM, Benjamin Marzinski wrote:
> >On Fri, Jan 29, 2016 at 02:10:52PM +, Nalla, Ravikanth wrote:
> >>Hi Mike, Hannes, Ben
> >>>This seems like a problem that has already been solved with path groups.
> >>>If the path(s) in your preferred path group are there, multipath will
> >>> use them. If not, then it will use your less preferred path(s), and
> >>> load balance across them > how ever you choose with the path_selectors.
> >>>
> >>>I admit that we don't have a path prioritizer that does a good job of
> >>> allowing users to manually pick a specific path to prefer. But it seems
> >>> to me that there is > >where we should be solving the issue.
> >>>
> >>Yes as mentioned , it appears that we will be able to achieve the same
> >> result using the above multipath{...} configuration. However as you
> >> mentioned I felt that it is not that user friendly in specify the path
> >> to prefer. So when you mentioned about solving the problem there, could
> >> you please clarify on what you had in mind and is there anything specific
> >> from our implementation that can be used there ?
> >>
> >
> >There are two changes that I'm working on.
> >
> >1. I'm adding an option for the alua prioritizer so that setting the
> >ALUA TPG Preferred Bit will cause the alau prioritizer to put that path
> >in a group by itself (with the highest priority). Currently if the
> >preferred bit is set for an active/optimized path, and there are other
> >active/optimized paths, they are all grouped together, and there is no
> >way to change that. So, for people with ALUA enabled hardware, they can
> >just enable the option, and set the Preferred Bit.
> >
> Hmm? I was under the distinct impression that it's exactly the other way
> round; at least in my code I have this:
>
> switch(aas) {
> case AAS_OPTIMIZED:
> rc = 50;
> break;
> case AAS_NON_OPTIMIZED:
> rc = 10;
> break;
> case AAS_LBA_DEPENDENT:
> rc = 5;
> break;
> case AAS_STANDBY:
> rc = 1;
> break;
> default:
> rc = 0;
> }
> if (priopath && aas != AAS_OPTIMIZED)
> rc += 80;
>
> ie any path with the 'prio' bit set will be getting a differen priority than
> those without. Consequently they'll be grouped into different priority
> groups.
> I'd be surprised if your code is different, but what do I know ...
No. That's only true if the path doesn't have AAS_OPTIMIZED set. So if
you have a non-optimized path with the pref bit set, it will be in a
group by itself. If the path is AAS_OPTIMIZED, the pref bit is ignored.
Like I mentioned before, you are the one who changed this
commit b330bf8a5e6a29b51af0d8b4088e0d8554e5cfb4
Author: Hannes Reinecke
Date: Tue Jul 16 09:12:54 2013 +0200
alua: Do not add preferred path priority for active/optimized
When a path is in active/optimized we should disregard the
'preferred path' bit when calculating the priority.
Otherwise we'll end up with having two different priorities
(one for 'active/optimized (preferred)' and one for
'active/optimized (non-preferred)').
Which will result in two different path groups and a
sub-optimal path usage.
Signed-off-by: Hannes Reinecke
Before this commit, it always used the pref bit. Again, like I said
before, I'm saying that this was the wrong thing to do. The Spec is
pretty vague on what you should expect to happen when you set to pref
bit. When the path was in a group by itself, I got complaints. Now that
the path is is a group with other active/optimized paths, I get
complaints. The only answer is to allow the user to say what they want
the pref bit to mean.
-Ben
> >2. For people that need to be able to control the exact priority, I'm
> >redoing the weighted handler to allow better ways to specify the paths
> >in a presistent manner. It won't be as simple as the alua method, but
> >it will be actually usable, unlike it's current state.
> >
> That, however, is greatly appreciated :-)
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke zSeries & Storage
> h...@suse.de+49 911 74053 688
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
Re: N900 sleep mode (in 4.5-rc0, if that matters)
On Sat 2016-01-30 21:02:45, Pavel Machek wrote: > Hi! > > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 > > > 000d 48004a28 (fa004a28) cm_idlest3_core > > > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems > > > constant. > > > > For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5 > > blocking which is for OTG and it's PHY. That's a known issue with > > musb and setting pm_runtime_irq_safe() on the MUSB parent. > > > > If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will > > start going off assuming the McSPI bit goes low with WLAN idling. > > Ok, so I tried to compile kernel without omap2430/phy-twl4030usb > . That did not help. So I thought, ok, maybe rmmod is needed to > trigger some powersaving? But that is not exactly easy to do: > > pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/omap2430.ko > pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/phy-twl4030-usb.ko > pavel@n900:/my/tui/ofone$ sudo rmmod phy-twl4030-usb.ko > Error: Module phy_twl4030_usb is in use > pavel@n900:/my/tui/ofone$ > > Any ideas what jumps to use the modules? Charger code? I tried a kernel without charger code, and no luck, rmmod fails the same way. dmesg says: [ 111.093078] wlan0: authenticated [ 111.097442] wlan0: associate with 06:27:22:f9:10:6a (try 1/3) [ 111.104553] wlan0: RX AssocResp from 06:27:22:f9:10:6a (capab=0x421 status=0 aid=2) [ 111.104705] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2), will use 2 [ 111.104736] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 3), will use 2 [ 111.256652] wlan0: associated [ 184.681427] HS USB OTG: no transceiver configured [ 184.681488] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [ 184.681976] HS USB OTG: no transceiver configured [ 184.682006] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [ 187.690338] twl4030_usb 4807.i2c:twl@48:twl4030-usb: Initialized TWL4030 USB module [ 187.698303] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) [ 187.698333] musb-hdrc: MHDRC RTL version 1.400 [ 187.698333] musb-hdrc: setup fifo_mode 4 [ 187.698394] musb-hdrc: 28/31 max ep, 16384/16384 memory pavel@n900:/my/tui/ofone$ Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[PATCH] media: Media Controller fix to not let stream_count go negative
Change media_entity_pipeline_stop() to not decrement
stream_count of an inactive media pipeline. Doing so,
results in preventing starting the pipeline.
Signed-off-by: Shuah Khan
---
drivers/media/media-entity.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index e89d85a..f2e4360 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -452,9 +452,12 @@ error:
media_entity_graph_walk_start(graph, entity_err);
while ((entity_err = media_entity_graph_walk_next(graph))) {
- entity_err->stream_count--;
- if (entity_err->stream_count == 0)
- entity_err->pipe = NULL;
+ /* don't let the stream_count go negative */
+ if (entity->stream_count > 0) {
+ entity_err->stream_count--;
+ if (entity_err->stream_count == 0)
+ entity_err->pipe = NULL;
+ }
/*
* We haven't increased stream_count further than this
@@ -486,9 +489,12 @@ void media_entity_pipeline_stop(struct media_entity
*entity)
media_entity_graph_walk_start(graph, entity);
while ((entity = media_entity_graph_walk_next(graph))) {
- entity->stream_count--;
- if (entity->stream_count == 0)
- entity->pipe = NULL;
+ /* don't let the stream_count go negative */
+ if (entity->stream_count > 0) {
+ entity->stream_count--;
+ if (entity->stream_count == 0)
+ entity->pipe = NULL;
+ }
}
if (!--pipe->streaming_count)
--
2.5.0
3-color led too bright
Hi! The indicator 3-color LED in mainline kernel seem to be a bit too bright. .. more bright to look at comfortably. I believe it is also brighter than in original maemo... I believe I've seen note somewhere that hardware may allow too much current to the 3-color led damaging hardware... but I can't find the link now. Does anyone know more? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: N900 sleep mode (in 4.5-rc0, if that matters)
Hi! > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 > > 000d 48004a28 (fa004a28) cm_idlest3_core > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems > > constant. > > For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5 > blocking which is for OTG and it's PHY. That's a known issue with > musb and setting pm_runtime_irq_safe() on the MUSB parent. > > If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will > start going off assuming the McSPI bit goes low with WLAN idling. Ok, so I tried to compile kernel without omap2430/phy-twl4030usb . That did not help. So I thought, ok, maybe rmmod is needed to trigger some powersaving? But that is not exactly easy to do: pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/omap2430.ko pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/phy-twl4030-usb.ko pavel@n900:/my/tui/ofone$ sudo rmmod phy-twl4030-usb.ko Error: Module phy_twl4030_usb is in use pavel@n900:/my/tui/ofone$ Any ideas what jumps to use the modules? Charger code? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: 4.5-rc1: mm/gup.c warning when writing to /proc/self/mem
On Sat, Jan 30, 2016 at 12:58:31PM -0500, Dave Jones wrote:
> Hit this overnight. Just started seeing this after I added "create mmap's
> of fd's we open()'d" to trinity.
The WARN_ON_ONCE() came form Hugh's patch:
cda540ace6a1 ("mm: get_user_pages(write,force) refuse to COW in shared areas")
This warning is expected if you try to write via /proc//mem into
write-protected shared mapping without FMODE_WRITE on the underlying file.
You're not supposed to do that and -EFAULT is right answer for an attempt.
The WARN_ON_ONCE() was added almost two years ago to catch other not
expected users of get_user_pages(write=1,force=1). IIUC, none were found.
Probably we should consider removing the warning.
>
> Dave
>
> WARNING: CPU: 1 PID: 16733 at mm/gup.c:434 __get_user_pages+0x5f9/0x990()
> CPU: 1 PID: 16733 Comm: trinity-c30 Tainted: GW
> 4.5.0-rc1-think+ #12
> 0009 6648ff5c 88000f0779a0 99565971
> [ cut here ]
> WARNING: CPU: 0 PID: 16731 at mm/gup.c:434 __get_user_pages+0x5f9/0x990()
> 88000f0779e0 990b168f 992aba69
> 880450cf1000 88023780e600 0017
> Call Trace:
> [] dump_stack+0x4e/0x7d
> [] warn_slowpath_common+0x9f/0xe0
> [] ? __get_user_pages+0x5f9/0x990
> [] warn_slowpath_null+0x1a/0x20
> [] __get_user_pages+0x5f9/0x990
> [] ? follow_page_mask+0x530/0x530
> [] ? __access_remote_vm+0xca/0x340
> [] get_user_pages+0x52/0x60
> [] __access_remote_vm+0x190/0x340
> [] ? preempt_count_sub+0xc1/0x120
> [] ? __might_fault+0xf0/0xf0
> [] ? __might_fault+0x87/0xf0
> [] access_remote_vm+0x1f/0x30
> [] mem_rw.isra.15+0xe3/0x1d0
> [] mem_write+0x43/0x50
> [] __vfs_write+0xdd/0x260
> [] ? __vfs_read+0x260/0x260
> [] ? mutex_lock_nested+0x38b/0x590
> [] ? __lock_is_held+0x92/0xd0
> [] ? preempt_count_sub+0xc1/0x120
> [] ? update_fast_ctr+0x65/0x90
> [] ? percpu_down_read+0x57/0xa0
> [] ? __sb_start_write+0xb4/0xf0
> [] vfs_write+0xf6/0x260
> [] SyS_write+0xbf/0x160
> [] ? SyS_read+0x160/0x160
> [] ? trace_hardirqs_on_thunk+0x17/0x19
> [] entry_SYSCALL_64_fastpath+0x12/0x6b
> CPU: 0 PID: 16731 Comm: trinity-c28 Tainted: GW
> 4.5.0-rc1-think+ #12
> 0009 2962eec9 8802e7b7f8d8 99565971
> 8802e7b7f918 990b168f 992aba69
> 8803ed6f1000 00a0 88023780e600 0017
> Call Trace:
> [] dump_stack+0x4e/0x7d
> [] warn_slowpath_common+0x9f/0xe0
> [] ? __get_user_pages+0x5f9/0x990
> [] warn_slowpath_null+0x1a/0x20
> [] __get_user_pages+0x5f9/0x990
> [] ? native_sched_clock+0x69/0x160
> [] ? follow_page_mask+0x530/0x530
> [] ? __access_remote_vm+0xca/0x340
> [] get_user_pages+0x52/0x60
> [] __access_remote_vm+0x190/0x340
> [] ? preempt_count_sub+0xc1/0x120
> [] ? __might_fault+0xf0/0xf0
> [] ? __might_fault+0x87/0xf0
> [] access_remote_vm+0x1f/0x30
> [] mem_rw.isra.15+0xe3/0x1d0
> [] mem_write+0x43/0x50
> [] do_loop_readv_writev+0xe0/0x110
> [] ? mem_rw.isra.15+0x1d0/0x1d0
> [] do_readv_writev+0x38b/0x3c0
> [] ? trace_hardirqs_off_caller+0x70/0x110
> [] ? mem_rw.isra.15+0x1d0/0x1d0
> [] ? vfs_write+0x260/0x260
> [] ? debug_smp_processor_id+0x17/0x20
> [] ? preempt_count_sub+0xc1/0x120
> [] ? __lock_is_held+0x25/0xd0
> [] ? mark_held_locks+0x23/0xc0
> [] ? context_tracking_exit.part.5+0x2a/0x50
> [] ? trace_hardirqs_on_caller+0x186/0x280
> [] ? trace_hardirqs_on+0xd/0x10
> [] vfs_writev+0x59/0x70
> [] SyS_pwritev+0x15d/0x180
> [] ? SyS_preadv+0x180/0x180
> [] ? trace_hardirqs_on_thunk+0x17/0x19
> [] entry_SYSCALL_64_fastpath+0x12/0x6b
> ---[ end trace 96115a52264cceaf ]---
> ---[ end trace 96115a52264cceb0 ]---
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
Kirill A. Shutemov
Re: [PATCH] Remove ambiguous logging for "Unsupported brightness interface"
On Sat, 30 Jan 2016, Eric Curtin wrote:
> "Unsupported brightness interface" message gets logged on
> machines that are well supported.
>
> Signed-off-by: Eric Curtin
> ---
> drivers/platform/x86/thinkpad_acpi.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c
> b/drivers/platform/x86/thinkpad_acpi.c
> index a268a7a..e305ab5 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -6653,18 +6653,16 @@ static void __init
> tpacpi_detect_brightness_capabilities(void)
> switch (b) {
> case 16:
> bright_maxlvl = 15;
> - pr_info("detected a 16-level brightness capable ThinkPad\n");
> break;
> case 8:
> case 0:
> bright_maxlvl = 7;
> - pr_info("detected a 8-level brightness capable ThinkPad\n");
> break;
> default:
> - pr_info("Unsupported brightness interface\n");
> tp_features.bright_unkfw = 1;
> bright_maxlvl = b - 1;
> }
> + pr_debug("detected %u brightness levels\n", bright_maxlvl + 1);
> }
>
> static int __init brightness_init(struct ibm_init_struct *iibm)
Acked-by: Henrique de Moraes Holschuh
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Re: [PATCH v3] dmi: Make dmi_walk and dmi_walk_early return real error codes
On Sat, 30 Jan 2016 10:13:09 -0800, Andy Lutomirski wrote: > On Sat, Jan 30, 2016 at 10:05 AM, Darren Hart wrote: > > If I understand this correctly, this is the first of 5 patches, and this > > one has > > some unanswered questions from Jean here. If this patch gets respun, the > > following are also impacted: > > > > dell-wmi: Stop storing pointers to DMI tables > > dell-wmi, dell-laptop: select DMI > > dell-wmi: Clean up hotkey table size check > > dell-wmi: Support new hotkeys on the XPS 13 9350 (Skylake) > > > > Is that correct? > > Not really. It's just the three patches here: > > http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/8503 > > This patch (the dmi_walk error code one) is no longer really related. > Due to Jean's earlier comment about what happens if DMI isn't enabled > at all, I no longer propagate the error code from dmi_walk in > dell-wmi, so the error code won't have any effect. (Instead I just > warn and let the driver load in legacy mode, which matches the current > behavior.) > > I think the way to go is for the v3 "dell-wmi: DMI misuse fixes" > series to go in through your tree, and I'll hash out the error code > thing separately with Jean. > > Does that seem sensible? Yes, I agree that this patch is independent from the dell-wmi patch series now. -- Jean Delvare SUSE L3 Support
Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8
> > Just so you know, I have no intention of supporting this use case. In > fact, I'm planning to eventually stop using IST for #DB entirely, at > which point the kernel will crash terribly if this code is > single-stepped (except when using a hypervisor to do this single > stepping, which is a much more sensible way to handle it). I don't know what good using the userspace trap code is going to help with this, a hypervisor will crash too with sysret being used there -- I just tested it. So it breaks all debuggers, even the faux ones that run as user space apps. Your other suggestions will cause some mayhem too for debuggers. If you break something, I'll just unpatch it in my tree, so have fun. LOL Jeff
[PATCH 1/3] libnvdimm: fix mode determination for e820 devices
Correctly display "safe" mode when a btt is established on a e820/memmap defined pmem namespace. Signed-off-by: Dan Williams --- drivers/nvdimm/namespace_devs.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c index 8ebfcaae3f5a..9edf7eb7d17c 100644 --- a/drivers/nvdimm/namespace_devs.c +++ b/drivers/nvdimm/namespace_devs.c @@ -1277,10 +1277,12 @@ static ssize_t mode_show(struct device *dev, device_lock(dev); claim = ndns->claim; - if (pmem_should_map_pages(dev) || (claim && is_nd_pfn(claim))) - mode = "memory"; - else if (claim && is_nd_btt(claim)) + if (claim && is_nd_btt(claim)) mode = "safe"; + else if (claim && is_nd_pfn(claim)) + mode = "memory"; + else if (!claim && pmem_should_map_pages(dev)) + mode = "memory"; else mode = "raw"; rc = sprintf(buf, "%s\n", mode);
[PATCH 3/3] devm_memremap_pages: fix vmem_altmap lifetime + alignment handling
to_vmem_altmap() needs to return valid results until
arch_remove_memory() completes. It also needs to be valid for any pfn
in a section regardless of whether that pfn maps to data. This escape
was a result of a bug in the unit test.
The signature of this bug is that free_pagetable() fails to retrieve a
vmem_altmap and goes off into the weeds:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] get_pfnblock_flags_mask+0x49/0x60
[..]
Call Trace:
[] free_hot_cold_page+0x97/0x1d0
[] __free_pages+0x2a/0x40
[] free_pagetable+0x8c/0xd4
[] remove_pagetable+0x37a/0x808
[] vmemmap_free+0x10/0x20
Fixes: 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Cc: Andrew Morton
Reported-by: Jeff Moyer
Signed-off-by: Dan Williams
---
kernel/memremap.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/kernel/memremap.c b/kernel/memremap.c
index e517a16cb426..cbc3e97e2bb4 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -183,7 +183,11 @@ EXPORT_SYMBOL(put_zone_device_page);
static void pgmap_radix_release(struct resource *res)
{
- resource_size_t key;
+ resource_size_t key, align_start, align_size, align_end;
+
+ align_start = res->start & ~(SECTION_SIZE - 1);
+ align_size = ALIGN(resource_size(res), SECTION_SIZE);
+ align_end = align_start + align_size - 1;
mutex_lock(_lock);
for (key = res->start; key <= res->end; key += SECTION_SIZE)
@@ -226,12 +230,11 @@ static void devm_memremap_pages_release(struct device
*dev, void *data)
percpu_ref_put(pgmap->ref);
}
- pgmap_radix_release(res);
-
/* pages are dead and unused, undo the arch mapping */
align_start = res->start & ~(SECTION_SIZE - 1);
align_size = ALIGN(resource_size(res), SECTION_SIZE);
arch_remove_memory(align_start, align_size);
+ pgmap_radix_release(res);
dev_WARN_ONCE(dev, pgmap->altmap && pgmap->altmap->alloc,
"%s: failed to free all reserved pages\n", __func__);
}
@@ -267,7 +270,7 @@ void *devm_memremap_pages(struct device *dev, struct
resource *res,
{
int is_ram = region_intersects(res->start, resource_size(res),
"System RAM");
- resource_size_t key, align_start, align_size;
+ resource_size_t key, align_start, align_size, align_end;
struct dev_pagemap *pgmap;
struct page_map *page_map;
unsigned long pfn;
@@ -309,7 +312,10 @@ void *devm_memremap_pages(struct device *dev, struct
resource *res,
mutex_lock(_lock);
error = 0;
- for (key = res->start; key <= res->end; key += SECTION_SIZE) {
+ align_start = res->start & ~(SECTION_SIZE - 1);
+ align_size = ALIGN(resource_size(res), SECTION_SIZE);
+ align_end = align_start + align_size - 1;
+ for (key = align_start; key <= align_end; key += SECTION_SIZE) {
struct dev_pagemap *dup;
rcu_read_lock();
@@ -336,8 +342,6 @@ void *devm_memremap_pages(struct device *dev, struct
resource *res,
if (nid < 0)
nid = numa_mem_id();
- align_start = res->start & ~(SECTION_SIZE - 1);
- align_size = ALIGN(resource_size(res), SECTION_SIZE);
error = arch_add_memory(nid, align_start, align_size, true);
if (error)
goto err_add_memory;
[PATCH 0/3] libnvdimm: fix memmap in pmem support
Thanks to Jeff for pointing out a thinko in the ndctl implementation of create-namespace. That bug was covering up the fact that vmem_altmap handling broke when 'pgmap_radix' was introduced to replace the list based method [1]. The other two fixes fell out from further expanding the unit tests. [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-December/003608.html --- Dan Williams (3): libnvdimm: fix mode determination for e820 devices libnvdimm, pfn: fix restoring memmap location devm_memremap_pages: fix vmem_altmap lifetime + alignment handling drivers/nvdimm/namespace_devs.c |8 +--- drivers/nvdimm/pfn_devs.c |4 +--- kernel/memremap.c | 18 +++--- 3 files changed, 17 insertions(+), 13 deletions(-)
[PATCH 2/3] libnvdimm, pfn: fix restoring memmap location
This path was missed when turning on the memmap in pmem support. Permit
'pmem' as a valid location for the map.
Reported-by: Jeff Moyer
Signed-off-by: Dan Williams
---
drivers/nvdimm/pfn_devs.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index 0cc9048b86e2..ae81a2f1da50 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -301,10 +301,8 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn)
switch (le32_to_cpu(pfn_sb->mode)) {
case PFN_MODE_RAM:
- break;
case PFN_MODE_PMEM:
- /* TODO: allocate from PMEM support */
- return -ENOTTY;
+ break;
default:
return -ENXIO;
}
Re: [PATCH 3/4] netfilter: ipv4: use preferred kernel types
On Sat, Jan 30, 2016 at 4:26 PM, Joe Perches wrote: > On Sat, 2016-01-30 at 09:51 -0800, Eric Dumazet wrote: >> On Sat, 2016-01-30 at 12:05 -0200, Lucas Tanure wrote: >> > On Sat, Jan 30, 2016 at 11:45 AM, Patrick McHardy wrote: >> > > On 30.01, Lucas Tanure wrote: >> > > > As suggested by checkpatch.pl: >> > > > CHECK: Prefer kernel type 'uX' over 'uintX_t' >> > > >> > > You might have noticed we have literally hundreds of them spread over 100 >> > > files in the netfilter code. We'll gradually change them when the code is >> > > touched anyways. >> > > >> > > > net/ipv4/netfilter/ip_tables.c | 5 ++--- >> > > > 1 file changed, 2 insertions(+), 3 deletions(-) >> > >> > Yes, I checked that. But would be better to change that now? >> > Because: >> > - could take years to anyone to touch the code, as the code already >> > works very well >> > - be more standardized could facilitate reading the code >> > - It's a good way to encourage new people to contribute to the code >> > >> > Thanks! >> >> These changes are a pain for people having to constantly backport fixes >> into stable kernels, or rebase their patches before upstream >> submissions. >> >> Things like 'git cherry-pick' , 'git rebase' no longer work. >> This is a huge pain, and manual editing to resolve conflicts often >> add bugs. >> >> Really, do you believe the 'uX' over 'uintX_t' stuff really matters for >> people working on adding new features and fixing bugs ? >> >> I am certain that if you had to work like us, you would quickly see the >> utility of such changes is negative. >> >> Sure, new submissions should be clean, but 'fixing' old code is not >> worth it. > > That might depend on whether or not the linux kernel is > a "long-life project" and whether or no any old branch > of it is also important and sufficiently long-life. > > The active life of a backport branch for the linux kernel > seems to be 3 or 4 years. The linux kernel will likely > be useful for a few more decades beyond that. > > Complex and long-life projects like the linux kernel > might benefit more in code complexity reduction patches > like these rather than code stasis for backward porting > ease. > > In general, arguing for stasis leads to ossification, > slow decline. > > Change for change's sake is poor, but changes to reduce > complexity, improve maintainability (for some measure of > it) and especially improve performance should be > welcomed where feasible. > My goal was to improve maintainability for the code, and with time, contribute with meaningful code. As you might have noticed I didn't fix every checkpatch.pl warning and error. I just sent the ones that I thought would improve the maintainability. And backport fixes will always be a pain, no matter what. Thanks for all the comments. Sorry for anything.
