Re: [PATCH v4] openrisc: irq: use irqchip framework
On Fri, Jun 20, 2014 at 10:04:30PM -0400, Jason Cooper wrote: > On Thu, May 29, 2014 at 11:28:08PM +0300, Stefan Kristiansson wrote: > > But I don't understand the purpose of the versioning here, > > there will never be any other or1200-pic version than the one that currently > > exists, so IMO "or1200" should be enough versioning information. > > I'm horribly unfamiliar with openrisc, but compatible strings are > compatible strings. ;-) > > Is the *actual* IP block called or1200-pic? Or is it, eg or1235-pic, and > you're using or1200-pic as a generic catch-all? > No, the or1200-pic is a part of the or1200 cpu that is one (there are several others) implementation of the OpenRISC 1000 architecture. The quirk here is that the OpenRISC 1000 architecture specification specifies how a PIC should be implemented, but or1200 doesn't follow that to 100%. Thus, it need a bit of special care. The implementations that follow the specification can use the or1k-pic-level and or1k-pic-edge variants. > Please use the specific IP name without wildcards. That compatible > string will then be used on that IP and future IP that is compatible > with the original IP. Once an incompatible change is introduced, then > we'll create a new compatible string, say or1300-pic, or or1237-pic. > The point I tried to make above was that if a change would be made to the pic implementation in or1200, it should be a change to conform to the specification. > When in doubt, be specific. I don't think the '-rtlsvnXYZ' should be > necessary, though. > I agree, and I think 'or1200-pic' is specific enough in this case. Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove csum_partial_copy_generic_i386 to clean up exception table
On Thu, Jun 05, 2014 at 11:49:49PM +0200, Richard Weinberger wrote: > Am 05.06.2014 06:15, schrieb Honggang Li: > > arch/x86/um/checksum_32.S had been copy & paste from x86. When build > > x86 uml, csum_partial_copy_generic_i386 mess up the exception table. > > In fact, exception table dose not work in uml kernel. > > Are you sure that exception tables do not work on UML? > I said, I'm not sure. Can you please find out? Hi, After traced i386 uml kernel with gdb , I'm sure exception tables do *not* work. When csum_partial_copy_generic_i386 read user space memory, an access error exception arises, however, the segv function always return zero. So, the fixup nerver executed. The uml system hang (not kernel panic). thanks. > > In arch/um/kernel/trap.c:segv() we have the mechanism for it: > else if (!is_user && arch_fixup(ip, regs)) > goto out; > > The interesting question is, is this by design or was it just copy&pasted > from x86 > many moons ago? :) > > > And csum_partial_copy_generic_i386 never been called. So, delete it. > > I like such clean ups. :-) > > Thanks, > //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v3.10-rt / v3.12-rt] scheduling while atomic in cgroup code
On Sat, 2014-06-21 at 07:55 +0400, Nikita Yushchenko wrote:
> Hi.
>
> Call Trace:
> [e22d5a90] [c0007ea8] show_stack+0x4c/0x168 (unreliable)
> [e22d5ad0] [c0618c04] __schedule_bug+0x94/0xb0
> [e22d5ae0] [c060b9ec] __schedule+0x530/0x550
> [e22d5bf0] [c060bacc] schedule+0x30/0xbc
> [e22d5c00] [c060ca24] rt_spin_lock_slowlock+0x180/0x27c
> [e22d5c70] [c00b39dc] res_counter_uncharge_until+0x40/0xc4
> [e22d5ca0] [c013ca88] drain_stock.isra.20+0x54/0x98
> [e22d5cc0] [c01402ac] __mem_cgroup_try_charge+0x2e8/0xbac
> [e22d5d70] [c01410d4] mem_cgroup_charge_common+0x3c/0x70
> [e22d5d90] [c0117284] __do_fault+0x38c/0x510
> [e22d5df0] [c011a5f4] handle_pte_fault+0x98/0x858
> [e22d5e50] [c060ed08] do_page_fault+0x42c/0x6fc
> [e22d5f40] [c000f5b4] handle_page_fault+0xc/0x80
>
> What happens:
>
> - refill_stock() calls get_cpu_var() and thus disables preemption until
> matching put_cpu_var() is called,
>
> - then it calls drain_stock() -> res_counter_uncharge() ->
> res_counter_uncharge_until()
>
> - and here we have spin_lock(), which under RT can sleep. Thus we have
> sleeping with preemption disabled.
>
>
> Any ideas how to fix?
The below should work.. though not as well as turning it off.
mm, memcg: make refill_stock()/consume_stock() use get_cpu_light()
Nikita reported the following memcg scheduling while atomic bug:
Call Trace:
[e22d5a90] [c0007ea8] show_stack+0x4c/0x168 (unreliable)
[e22d5ad0] [c0618c04] __schedule_bug+0x94/0xb0
[e22d5ae0] [c060b9ec] __schedule+0x530/0x550
[e22d5bf0] [c060bacc] schedule+0x30/0xbc
[e22d5c00] [c060ca24] rt_spin_lock_slowlock+0x180/0x27c
[e22d5c70] [c00b39dc] res_counter_uncharge_until+0x40/0xc4
[e22d5ca0] [c013ca88] drain_stock.isra.20+0x54/0x98
[e22d5cc0] [c01402ac] __mem_cgroup_try_charge+0x2e8/0xbac
[e22d5d70] [c01410d4] mem_cgroup_charge_common+0x3c/0x70
[e22d5d90] [c0117284] __do_fault+0x38c/0x510
[e22d5df0] [c011a5f4] handle_pte_fault+0x98/0x858
[e22d5e50] [c060ed08] do_page_fault+0x42c/0x6fc
[e22d5f40] [c000f5b4] handle_page_fault+0xc/0x80
What happens:
refill_stock()
get_cpu_var()
drain_stock()
res_counter_uncharge()
res_counter_uncharge_until()
spin_lock() <== boom
Fix it by replacing get/put_cpu_var() with get/put_cpu_light().
Reported-by: Nikita Yushchenko
Signed-off-by: Mike Galbraith
---
mm/memcontrol.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2398,16 +2398,18 @@ static bool consume_stock(struct mem_cgr
{
struct memcg_stock_pcp *stock;
bool ret = true;
+ int cpu;
if (nr_pages > CHARGE_BATCH)
return false;
- stock = &get_cpu_var(memcg_stock);
+ cpu = get_cpu_light();
+ stock = &per_cpu(memcg_stock, cpu);
if (memcg == stock->cached && stock->nr_pages >= nr_pages)
stock->nr_pages -= nr_pages;
else /* need to call res_counter_charge */
ret = false;
- put_cpu_var(memcg_stock);
+ put_cpu_light();
return ret;
}
@@ -2457,14 +2459,17 @@ static void __init memcg_stock_init(void
*/
static void refill_stock(struct mem_cgroup *memcg, unsigned int nr_pages)
{
- struct memcg_stock_pcp *stock = &get_cpu_var(memcg_stock);
+ struct memcg_stock_pcp *stock;
+ int cpu = get_cpu_light();
+
+ stock = &per_cpu(memcg_stock, cpu);
if (stock->cached != memcg) { /* reset if necessary */
drain_stock(stock);
stock->cached = memcg;
}
stock->nr_pages += nr_pages;
- put_cpu_var(memcg_stock);
+ put_cpu_light();
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] net/dsa/dsa.c: remove null test before kfree
On 20 June 2014 22:36:47 CEST, Fabian Frederick wrote: >Fix checkpatch warning: >WARNING: kfree(NULL) is safe this check is probably not required "probably not" implies that there are cases where the check *is* required. That means that your commit message should explain why this particular check is redundant. I haven't analyzed your changes here, so they could be fine for all I know. My point is that such analysis is your job when submitting cleanups like this one. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: lustre: fix sparse warnings for static symbols
This patch fixes the following sparse warnings: drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:46:20: warning: symbol 'the_ksocklnd' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:49:19: warning: symbol 'ksocknal_ip2iface' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:67:15: warning: symbol 'ksocknal_create_route' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:103:1: warning: symbol 'ksocknal_create_peer' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:218:1: warning: symbol 'ksocknal_unlink_peer_locked' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:248:1: warning: symbol 'ksocknal_get_peer_info' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:323:1: warning: symbol 'ksocknal_associate_route_conn_locked' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:368:1: warning: symbol 'ksocknal_add_route_locked' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:409:1: warning: symbol 'ksocknal_del_route_locked' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:511:1: warning: symbol 'ksocknal_del_peer_locked' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:566:1: warning: symbol 'ksocknal_del_peer' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:624:14: warning: symbol 'ksocknal_get_conn_by_idx' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:661:15: warning: symbol 'ksocknal_choose_scheduler_locked' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:685:1: warning: symbol 'ksocknal_local_ipvec' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:713:1: warning: symbol 'ksocknal_match_peerip' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:745:1: warning: symbol 'ksocknal_select_ips' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:847:1: warning: symbol 'ksocknal_create_routes' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:997:1: warning: symbol 'ksocknal_connecting' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:1853:1: warning: symbol 'ksocknal_push_peer' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:1886:1: warning: symbol 'ksocknal_push' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:1935:1: warning: symbol 'ksocknal_add_interface' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:1997:1: warning: symbol 'ksocknal_peer_del_interface_locked' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2038:1: warning: symbol 'ksocknal_del_interface' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2213:1: warning: symbol 'ksocknal_free_buffers' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2256:1: warning: symbol 'ksocknal_base_shutdown' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2349:1: warning: symbol 'ksocknal_new_incarnation' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2364:1: warning: symbol 'ksocknal_base_startup' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2496:1: warning: symbol 'ksocknal_debug_peerhash' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2603:1: warning: symbol 'ksocknal_enumerate_interfaces' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2660:1: warning: symbol 'ksocknal_search_new_ipif' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2702:1: warning: symbol 'ksocknal_start_schedulers' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2748:1: warning: symbol 'ksocknal_net_start_threads' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2860:1: warning: symbol 'ksocknal_module_fini' was not declared. Should it be static? drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2866:1: warning: symbol 'ksocknal_module_init' was not declared. Should it be static? Signed-off-by: James A Shackleford --- .../staging/lustre/lnet/klnds/socklnd/socklnd.c| 70 ++-- 1 file changed, 35 insertions(+
Re: [PATCHv6 1/3] devicetree: Addition of the Altera SDRAM controller
Hi!
On Fri, Jun 20, 2014 at 06:22:01PM -0500, ttha...@altera.com wrote:
> From: Thor Thayer
>
> Addition of the Altera SDRAM Controller bindings and device tree changes.
>
> v2: Changes to SoC SDRAM EDAC code.
>
> v3: Implement code suggestions for SDRAM EDAC code.
>
> v4: Remove syscon from SDRAM controller bindings.
>
> v5: No Change, bump version for consistency.
>
> v6: Only map the ctrlcfg register as syscon.
>
> Signed-off-by: Thor Thayer
> ---
> .../bindings/arm/altera/socfpga-sdram.txt | 11 +++
> arch/arm/boot/dts/socfpga.dtsi |5 +
> 2 files changed, 16 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
> b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
> new file mode 100644
> index 000..5027026
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
> @@ -0,0 +1,11 @@
> +Altera SOCFPGA SDRAM Controller
> +
> +Required properties:
> +- compatible : "altr,sdr-ctl";
> +- reg : Should contain 1 register ranges(address and length)
> +
> +Example:
> + sdrctl@ffc25000 {
> + compatible = "altr,sdr-ctl";
> + reg = <0xffc25000 0x4>;
> + };
> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> index 4676f25..310292e 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -682,6 +682,11 @@
> clocks = <&l4_sp_clk>;
> };
>
> + sdrctl@ffc25000 {
> + compatible = "altr,sdr-ctl", "syscon";
Did you forget to add the syscon to the binding documentation?
> + reg = <0xffc25000 0x4>;
> + };
> +
> rst: rstmgr@ffd05000 {
> compatible = "altr,rst-mgr";
> reg = <0xffd05000 0x1000>;
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv6 2/3] devicetree: Addition of the Altera SDRAM EDAC
On Fri, Jun 20, 2014 at 06:22:02PM -0500, ttha...@altera.com wrote:
> From: Thor Thayer
>
> Addition of the Altera SDRAM EDAC bindings and device tree changes
>
> v2: Changes to SoC EDAC source code.
>
> v3: Fix typo in device tree documentation.
>
> v4,v5: No changes - bump version for consistency.
>
> v6: Assign ECC registers in SDRAM controller to EDAC
>
> Signed-off-by: Thor Thayer
> ---
> .../bindings/arm/altera/socfpga-sdram-edac.txt | 15 +++
> arch/arm/boot/dts/socfpga.dtsi |6 ++
> 2 files changed, 21 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt
>
> diff --git
> a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt
> b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt
> new file mode 100644
> index 000..540c9cf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt
> @@ -0,0 +1,15 @@
> +Altera SOCFPGA SDRAM Error Detection & Correction [EDAC]
> +
> +Required properties:
> +- compatible : should contain "altr,sdram-edac";
> +- reg : should contain the ECC register range in sdram
> +controller (address and length).
> +- interrupts : Should contain the SDRAM ECC IRQ in the
> + appropriate format for the IRQ controller.
> +
> +Example:
> + sdramedac@0 {
> + compatible = "altr,sdram-edac";
> + reg = <0xffc2502C 0x28>;
> + interrupts = <0 39 4>;
> + };
> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> index 310292e..fe9832e 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -687,6 +687,12 @@
> reg = <0xffc25000 0x4>;
> };
>
> + sdramedac@0 {
^^^
Please fix the baseaddress (also in the binding doc).
> + compatible = "altr,sdram-edac";
> + reg = <0xffc2502C 0x28>;
> + interrupts = <0 39 4>;
> + };
> +
> rst: rstmgr@ffd05000 {
> compatible = "altr,rst-mgr";
> reg = <0xffd05000 0x1000>;
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] /proc/stat vs. failed order-4 allocation
On Wed, Jun 18, 2014 at 02:29:31PM -0700, Andrew Morton wrote: > On Mon, 16 Jun 2014 11:04:50 +0200 Heiko Carstens > wrote: > > > These two patches are supposed to "fix" failed order-4 memory > > allocations which have been observed when reading /proc/stat. > > The problem has been observed on s390 as well as on x86. > > > > To address the problem change the seq_file memory allocations to > > fallback to use vmalloc, so that allocations also work if memory > > is fragmented. > > > > This approach seems to be simpler and less intrusive than changing > > /proc/stat to use an interator. Also it "fixes" other users as well, > > which use seq_file's single_open() interface. > > Yes, those changes look pretty simple and effective. > > I'm unclear on how urgent these fixes are. I semi-randomly tagged them > for 3.16 with a -stable backport, but that could be changed? I assume tagged for 3.16 means you intend to get it merged before 3.16 gets released? If so, then that would be fine with me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] net/dsa/dsa.c: remove null test before kfree
On Sat, 21 Jun 2014 10:37:24 +0200
Bjørn Mork wrote:
>
>
> On 20 June 2014 22:36:47 CEST, Fabian Frederick wrote:
> >Fix checkpatch warning:
> >WARNING: kfree(NULL) is safe this check is probably not required
>
> "probably not" implies that there are cases where the check *is* required.
> That means that your commit message should explain why this particular check
> is redundant.
>
> I haven't analyzed your changes here, so they could be fine for all I know.
> My point is that such analysis is your job when submitting cleanups like this
> one.
>
>
>
AFAIK, any
if(foo)
kfree(foo)
can be updated to kfree(foo) but
if (foo){
kfree(foo)
do something else
}
has to be evaluated ; reason for the "probably" in warning message.
If I'm wrong maybe we could be more verbose in checkpatch :)
(I added Joe Perches in Cc list ; maybe he can help here)
Fabian
> Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
BUG when trying to use deadline iosched in 3.16-rc1
Hi, While testing 3.16-rc1, I got this error: Jun 21 11:19:03 brouette kernel: kernel tried to execute NX-protected page - exploit attempt? (uid: 0) Jun 21 11:19:03 brouette kernel: BUG: unable to handle kernel paging request at 8171a1f8 Jun 21 11:19:03 brouette kernel: IP: [] elv_register+0x0/0x197 Jun 21 11:19:03 brouette kernel: PGD 163d067 PUD 163e063 PMD 1b887f063 PTE 8171a163 Jun 21 11:19:03 brouette kernel: Oops: 0011 [#1] PREEMPT SMP Jun 21 11:19:03 brouette kernel: Modules linked in: deadline_iosched(+) binfmt_misc hid_roccat_konepure hid_roccat hid_roccat_common hid_generic snd_usb_audio snd_usbmidi_lib usbhid snd_hwdep snd_hda_codec_realtek snd_hda_codec_generic nouveau wmi snd_ca0106 video snd_ac97_codec i2c_algo_bit ttm snd_seq_dummy ac97_bus snd_seq_midi drm_kms_helper snd_seq_oss drm snd_seq_midi_event i2c_core snd_seq pcspkr sr_mod backlight snd_hda_intel snd_rawmidi snd_hda_controller cdrom snd_hda_codec snd_seq_device snd_pcm_oss snd_mixer_oss uhci_hcd ehci_pci snd_pcm ehci_hcd nvidiafb snd_timer usbcore vgastate usb_common evdev acpi_cpufreq loop fuse autofs4 Jun 21 11:19:03 brouette kernel: CPU: 1 PID: 2410 Comm: modprobe Tainted: P O 3.16.0-rc1 #1 Jun 21 11:19:03 brouette kernel: Hardware name: System manufacturer System Product Name/P6T SE, BIOS 080803/08/2010 Jun 21 11:19:03 brouette kernel: task: 8801b7c25b00 ti: 8801b4224000 task.ti: 8801b4224000 Jun 21 11:19:03 brouette kernel: RIP: 0010:[] [] elv_register+0x0/0x197 Jun 21 11:19:03 brouette kernel: RSP: 0018:8801b4227d60 EFLAGS: 00010246 Jun 21 11:19:03 brouette kernel: RAX: 8801b55a2101 RBX: 81641040 RCX: 03be0001 Jun 21 11:19:03 brouette kernel: RDX: 03bde001 RSI: 815a9f0d RDI: a103b880 Jun 21 11:19:03 brouette kernel: RBP: 8801b4227d68 R08: 000148e0 R09: Jun 21 11:19:03 brouette kernel: R10: 0012 R11: 00011c00 R12: 8801b55a2980 Jun 21 11:19:03 brouette kernel: R13: R14: a103d000 R15: a103ba40 Jun 21 11:19:03 brouette kernel: FS: 7f50c9669700() GS:8801bfc2() knlGS: Jun 21 11:19:03 brouette kernel: CS: 0010 DS: ES: CR0: 8005003b Jun 21 11:19:03 brouette kernel: CR2: 8171a1f8 CR3: 0001b7b1c000 CR4: 07e0 Jun 21 11:19:03 brouette kernel: Stack: Jun 21 11:19:03 brouette kernel: a103d010 8801b4227dd8 810002c4 0001 Jun 21 11:19:03 brouette kernel: 0001 a103ba40 8801b4227db8 810ed74a Jun 21 11:19:03 brouette kernel: 8801b4227ef8 a103ba58 a103ba90 8801b4227ef8 Jun 21 11:19:03 brouette kernel: Call Trace: Jun 21 11:19:03 brouette kernel: [] ? deadline_init+0x10/0x12 [deadline_iosched] Jun 21 11:19:03 brouette kernel: [] do_one_initcall+0x84/0x1c0 Jun 21 11:19:03 brouette kernel: [] ? __vunmap+0x9a/0x100 Jun 21 11:19:03 brouette kernel: [] load_module+0x19bc/0x2160 Jun 21 11:19:03 brouette kernel: [] ? symbol_put_addr+0x40/0x40 Jun 21 11:19:03 brouette kernel: [] SyS_finit_module+0x76/0x80 Jun 21 11:19:03 brouette kernel: [] system_call_fastpath+0x16/0x1b Jun 21 11:19:03 brouette kernel: Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jun 21 11:19:03 brouette kernel: RIP [] elv_register+0x0/0x197 Jun 21 11:19:03 brouette kernel: RSP Jun 21 11:19:03 brouette kernel: CR2: 8171a1f8 Jun 21 11:19:03 brouette kernel: ---[ end trace 5bbf40f5ac5f66e3 ]--- Jun 21 11:19:03 brouette kernel: elevator: type deadline not found Jun 21 11:19:03 brouette kernel: elevator: switch to deadline My startup scripts do this: echo "noop" > /sys/block/sda/queue/scheduler echo "deadline" > /sys/block/sdb/queue/scheduler echo "noop" > /sys/block/sdc/queue/scheduler echo "deadline" > /sys/block/sdd/queue/scheduler And the relevant part of my .config: CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_DEFAULT_IOSCHED="cfq" Maybe related to b5097e956a ? No problem with 3.15. Thanks, -- Damien Wyart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG when trying to use deadline iosched in 3.16-rc1
Hi, While testing 3.16-rc1, I got this error: Jun 21 11:19:03 brouette kernel: kernel tried to execute NX-protected page - exploit attempt? (uid: 0) Jun 21 11:19:03 brouette kernel: BUG: unable to handle kernel paging request at 8171a1f8 Jun 21 11:19:03 brouette kernel: IP: [] elv_register+0x0/0x197 Jun 21 11:19:03 brouette kernel: PGD 163d067 PUD 163e063 PMD 1b887f063 PTE 8171a163 Jun 21 11:19:03 brouette kernel: Oops: 0011 [#1] PREEMPT SMP Jun 21 11:19:03 brouette kernel: Modules linked in: deadline_iosched(+) binfmt_misc hid_roccat_konepure hid_roccat hid_roccat_common hid_generic snd_usb_audio snd_usbmidi_lib usbhid snd_hwdep snd_hda_codec_realtek snd_hda_codec_generic nouveau wmi snd_ca0106 video snd_ac97_codec i2c_algo_bit ttm snd_seq_dummy ac97_bus snd_seq_midi drm_kms_helper snd_seq_oss drm snd_seq_midi_event i2c_core snd_seq pcspkr sr_mod backlight snd_hda_intel snd_rawmidi snd_hda_controller cdrom snd_hda_codec snd_seq_device snd_pcm_oss snd_mixer_oss uhci_hcd ehci_pci snd_pcm ehci_hcd nvidiafb snd_timer usbcore vgastate usb_common evdev acpi_cpufreq loop fuse autofs4 Jun 21 11:19:03 brouette kernel: CPU: 1 PID: 2410 Comm: modprobe Tainted: P O 3.16.0-rc1 #1 Jun 21 11:19:03 brouette kernel: Hardware name: System manufacturer System Product Name/P6T SE, BIOS 080803/08/2010 Jun 21 11:19:03 brouette kernel: task: 8801b7c25b00 ti: 8801b4224000 task.ti: 8801b4224000 Jun 21 11:19:03 brouette kernel: RIP: 0010:[] [] elv_register+0x0/0x197 Jun 21 11:19:03 brouette kernel: RSP: 0018:8801b4227d60 EFLAGS: 00010246 Jun 21 11:19:03 brouette kernel: RAX: 8801b55a2101 RBX: 81641040 RCX: 03be0001 Jun 21 11:19:03 brouette kernel: RDX: 03bde001 RSI: 815a9f0d RDI: a103b880 Jun 21 11:19:03 brouette kernel: RBP: 8801b4227d68 R08: 000148e0 R09: Jun 21 11:19:03 brouette kernel: R10: 0012 R11: 00011c00 R12: 8801b55a2980 Jun 21 11:19:03 brouette kernel: R13: R14: a103d000 R15: a103ba40 Jun 21 11:19:03 brouette kernel: FS: 7f50c9669700() GS:8801bfc2() knlGS: Jun 21 11:19:03 brouette kernel: CS: 0010 DS: ES: CR0: 8005003b Jun 21 11:19:03 brouette kernel: CR2: 8171a1f8 CR3: 0001b7b1c000 CR4: 07e0 Jun 21 11:19:03 brouette kernel: Stack: Jun 21 11:19:03 brouette kernel: a103d010 8801b4227dd8 810002c4 0001 Jun 21 11:19:03 brouette kernel: 0001 a103ba40 8801b4227db8 810ed74a Jun 21 11:19:03 brouette kernel: 8801b4227ef8 a103ba58 a103ba90 8801b4227ef8 Jun 21 11:19:03 brouette kernel: Call Trace: Jun 21 11:19:03 brouette kernel: [] ? deadline_init+0x10/0x12 [deadline_iosched] Jun 21 11:19:03 brouette kernel: [] do_one_initcall+0x84/0x1c0 Jun 21 11:19:03 brouette kernel: [] ? __vunmap+0x9a/0x100 Jun 21 11:19:03 brouette kernel: [] load_module+0x19bc/0x2160 Jun 21 11:19:03 brouette kernel: [] ? symbol_put_addr+0x40/0x40 Jun 21 11:19:03 brouette kernel: [] SyS_finit_module+0x76/0x80 Jun 21 11:19:03 brouette kernel: [] system_call_fastpath+0x16/0x1b Jun 21 11:19:03 brouette kernel: Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jun 21 11:19:03 brouette kernel: RIP [] elv_register+0x0/0x197 Jun 21 11:19:03 brouette kernel: RSP Jun 21 11:19:03 brouette kernel: CR2: 8171a1f8 Jun 21 11:19:03 brouette kernel: ---[ end trace 5bbf40f5ac5f66e3 ]--- Jun 21 11:19:03 brouette kernel: elevator: type deadline not found Jun 21 11:19:03 brouette kernel: elevator: switch to deadline My startup scripts do this: echo "noop" > /sys/block/sda/queue/scheduler echo "deadline" > /sys/block/sdb/queue/scheduler echo "noop" > /sys/block/sdc/queue/scheduler echo "deadline" > /sys/block/sdd/queue/scheduler And the relevant part of my .config: CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_DEFAULT_IOSCHED="cfq" Maybe related to b5097e956a ? No problem with 3.15. Thanks, -- Damien Wyart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG when trying to use deadline iosched in 3.16-rc1
On Sat, 21 Jun 2014 11:37:47 +0200 Damien Wyart wrote: > Hi, > > While testing 3.16-rc1, I got this error: > > Jun 21 11:19:03 brouette kernel: kernel tried to execute NX-protected > page - exploit attempt? (uid: 0) > Jun 21 11:19:03 brouette kernel: BUG: unable to handle kernel paging > request at 8171a1f8 > Jun 21 11:19:03 brouette kernel: IP: [] > elv_register+0x0/0x197 > Jun 21 11:19:03 brouette kernel: PGD 163d067 PUD 163e063 PMD 1b887f063 > PTE 8171a163 > Jun 21 11:19:03 brouette kernel: Oops: 0011 [#1] PREEMPT SMP > Jun 21 11:19:03 brouette kernel: Modules linked in: deadline_iosched(+) > binfmt_misc hid_roccat_konepure hid_roccat hid_roccat_common hid_generic > snd_usb_audio snd_usbmidi_lib usbhid snd_hwdep snd_hda_codec_realtek > snd_hda_codec_generic nouveau wmi snd_ca0106 video snd_ac97_codec > i2c_algo_bit ttm snd_seq_dummy ac97_bus snd_seq_midi drm_kms_helper > snd_seq_oss drm snd_seq_midi_event i2c_core snd_seq pcspkr sr_mod > backlight snd_hda_intel snd_rawmidi snd_hda_controller cdrom > snd_hda_codec snd_seq_device snd_pcm_oss snd_mixer_oss uhci_hcd ehci_pci > snd_pcm ehci_hcd nvidiafb snd_timer usbcore vgastate usb_common evdev > acpi_cpufreq loop fuse autofs4 > Jun 21 11:19:03 brouette kernel: CPU: 1 PID: 2410 Comm: modprobe > Tainted: P O 3.16.0-rc1 #1 > Jun 21 11:19:03 brouette kernel: Hardware name: System manufacturer > System Product Name/P6T SE, BIOS 080803/08/2010 > Jun 21 11:19:03 brouette kernel: task: 8801b7c25b00 ti: > 8801b4224000 task.ti: 8801b4224000 > Jun 21 11:19:03 brouette kernel: RIP: 0010:[] > [] elv_register+0x0/0x197 > Jun 21 11:19:03 brouette kernel: RSP: 0018:8801b4227d60 EFLAGS: 00010246 > Jun 21 11:19:03 brouette kernel: RAX: 8801b55a2101 RBX: > 81641040 RCX: 03be0001 > Jun 21 11:19:03 brouette kernel: RDX: 03bde001 RSI: > 815a9f0d RDI: a103b880 > Jun 21 11:19:03 brouette kernel: RBP: 8801b4227d68 R08: > 000148e0 R09: > Jun 21 11:19:03 brouette kernel: R10: 0012 R11: > 00011c00 R12: 8801b55a2980 > Jun 21 11:19:03 brouette kernel: R13: R14: > a103d000 R15: a103ba40 > Jun 21 11:19:03 brouette kernel: FS: 7f50c9669700() > GS:8801bfc2() knlGS: > Jun 21 11:19:03 brouette kernel: CS: 0010 DS: ES: CR0: > 8005003b > Jun 21 11:19:03 brouette kernel: CR2: 8171a1f8 CR3: > 0001b7b1c000 CR4: 07e0 > Jun 21 11:19:03 brouette kernel: Stack: > Jun 21 11:19:03 brouette kernel: a103d010 8801b4227dd8 > 810002c4 0001 > Jun 21 11:19:03 brouette kernel: 0001 a103ba40 > 8801b4227db8 810ed74a > Jun 21 11:19:03 brouette kernel: 8801b4227ef8 a103ba58 > a103ba90 8801b4227ef8 > Jun 21 11:19:03 brouette kernel: Call Trace: > Jun 21 11:19:03 brouette kernel: [] ? > deadline_init+0x10/0x12 [deadline_iosched] > Jun 21 11:19:03 brouette kernel: [] > do_one_initcall+0x84/0x1c0 > Jun 21 11:19:03 brouette kernel: [] ? __vunmap+0x9a/0x100 > Jun 21 11:19:03 brouette kernel: [] > load_module+0x19bc/0x2160 > Jun 21 11:19:03 brouette kernel: [] ? > symbol_put_addr+0x40/0x40 > Jun 21 11:19:03 brouette kernel: [] > SyS_finit_module+0x76/0x80 > Jun 21 11:19:03 brouette kernel: [] > system_call_fastpath+0x16/0x1b > Jun 21 11:19:03 brouette kernel: Code: 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 > Jun 21 11:19:03 brouette kernel: RIP [] > elv_register+0x0/0x197 > Jun 21 11:19:03 brouette kernel: RSP > Jun 21 11:19:03 brouette kernel: CR2: 8171a1f8 > Jun 21 11:19:03 brouette kernel: ---[ end trace 5bbf40f5ac5f66e3 ]--- > Jun 21 11:19:03 brouette kernel: elevator: type deadline not found > Jun 21 11:19:03 brouette kernel: elevator: switch to deadline > > My startup scripts do this: > > echo "noop" > /sys/block/sda/queue/scheduler > echo "deadline" > /sys/block/sdb/queue/scheduler > echo "noop" > /sys/block/sdc/queue/scheduler > echo "deadline" > /sys/block/sdd/queue/scheduler > > And the relevant part of my .config: > > CONFIG_IOSCHED_NOOP=y > CONFIG_IOSCHED_DEADLINE=m > CONFIG_IOSCHED_CFQ=y > CONFIG_CFQ_GROUP_IOSCHED=y > CONFIG_DEFAULT_IOSCHED="cfq" > > > Maybe related to b5097e956a ? > > No problem with 3.15. It seems you're right. I didn't know that parameter could be updated dynamically. In that case, adding __init to elv_register was a bad idea because it's no more reliable. Could you revert that patch Jens ? Thanks, Fabian > > Thanks, > -- > Damien Wyart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the F
Re: [PATCH v2] clocksource: exynos-mct: Register the timer for stable udelay
On Fri, Jun 20, 2014 at 11:17 PM, Doug Anderson wrote: > Hi, > > On Fri, Jun 20, 2014 at 4:19 AM, amit daniel kachhap > wrote: >> On Fri, Jun 20, 2014 at 1:45 PM, Will Deacon wrote: >>> On Thu, Jun 19, 2014 at 05:40:49PM +0100, Tomasz Figa wrote: On 19.06.2014 18:31, Doug Anderson wrote: >>> My personal vote would be to submit a patch to change "cycles_t" to >>> always be 32-bits. Given that 32-bits was fine for udelay() for ARM >>> that seems sane and simple. If someone later comes up with a super >>> compelling reason why we need 64-bit timers for udelay (really??) then >>> they can later add all the complexity needed. >> >> Yes, this could work. I'm not sure what else cycles_t is used for, >> though. > > True, it is a bit questionable to change this since it's a type that's > not obviously just for udelay(). Perhaps a better option would be to > make a new typedef for the result of read_current_timer(). ...or just > change it to return a u32? > Sounds good to me, but let's hear other opinions. I'm adding Will and Jonathan as they wrote the ARM delay timer code. >>> >>> I think cycles_t is only used for small interval calculations at the moment, >>> but I remember Ted mentioning something about using it (or something >>> similar) as a source of early entropy, in which case the more bits the >>> better. >>> >> Will, >> Thanks for the clarification that cycles_t is used for short >> intervals. So it is safe to return lower 32 bit >> counter for read_current_timer. > > As I looked at it more, I realized that we have two types in Linux. > There's cycle_t and cycles_t. Whoa, confusing! > > I'd perhaps advocate a wholesale rename of cycles_t to avoid the > confusion. I don't have a good name for it, though. cycle32_t? Or > we could just use u32 for the function... :-/ or cycles_t can be renamed as short_cycle_t > > >> Tomasz, Doug, >> As of now let me send a minimal implementation of this read delay >> timer to fix the broken udelay for exynos platforms so that it goes to >> upstream in rc releases. I will also prepare a fix for all >> raw_readl/writel in mct to relaxed version to make it consistent. > > I'm reworking my 32-bit conversion patches right now and it's getting > messy to intermingle this with yours. I'm going to pick up your patch > and include it in my series. I hope that's OK. its fine and thanks for posting the series. > > My plan is: > > 1. For 3.16 I think it's important to fix the udelay() problems and > trying to rework cycle_t there doesn't seem like it makes sense. I'll > just use Amit's original code that uses exynos_frc_read(). It might > not be quite as optimal but it's good as a safe bugfix. > > 2. I'll post the cleanup patch moving away from the __raw_readl / __raw_writel > > 3. I'll post a patch moving to 32-bit, including moving Amit's code to > 32-bit but with a compile time warning for now. I'll add a KConfig > depends to keep it from compiling on ARM64. We can improve this once > we change the delay timer to always request 32-bits. > > -Doug > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Contact me for more details.
Hi friend. I want to transfer USD5.5Million into your account Contact me for more details. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8172u: Make ieee80211_crypto_init static
On Thu, Jun 19, 2014 at 05:14:26PM -0700, Greg Kroah-Hartman wrote:
> On Thu, Jun 12, 2014 at 07:40:49PM +0200, L. Alberto Giménez wrote:
> > Fix sparse warning.
> >
> > Signed-off-by: L. Alberto Giménez
> > ---
> > drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
> > b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
> > index 5533221..3be690d 100644
> > --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
> > +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
> > @@ -200,7 +200,7 @@ static struct ieee80211_crypto_ops ieee80211_crypt_null
> > = {
> > .owner = THIS_MODULE,
> > };
> >
> > -int __init ieee80211_crypto_init(void)
> > +static int __init ieee80211_crypto_init(void)
> > {
> > int ret = -ENOMEM;
>
> You obviously did not compile this change :(
>
> greg k-h
Hi Greg,
I'm very sorry for that, I swear I compiled it, but clearly I'm missing
something
here.
My patch compiles with a warning, but tag v3.15 (tag where my branch is based)
does
not issue this warning:
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c:203:19: warning:
‘ieee80211_crypto_init’ defined but not used [-Wunused-function]
static int __init ieee80211_crypto_init(void)
^
I thought that __init functions could be static, is there any problem with
that? Care
to shed some light here?
Thank you very much
--
L. Alberto Giménez
GnuPG key ID 0xDD4E27AB
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/mce: Don't unregister CPU hotplug notifier in error path
On Fri, Jun 20, 2014 at 10:04:37PM -0400, Boris Ostrovsky wrote: > I'll try it later but this doesn't look sufficient to me: we might not > reach this point if subsys_system_register() or zalloc_cpumask_var() > fail. If those fail, I'd say we have a much bigger problem than undeleted timers. > We could register the notifier as the first thing in this routine > (probably after mce_available() succeeds). I guess... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2 2/3] spi: qup: Fix order of spi_register_master
On Thu, Jun 12, 2014 at 02:34:11PM -0500, Andy Gross wrote: > This patch moves the devm_spi_register_master below the initialization of the > runtime_pm. If done in the wrong order, the spi_register_master fails if any > probed slave devices issue SPI transactions. Applied, thanks. signature.asc Description: Digital signature
Re: [Patch v2 1/3] spi: qup: Remove chip select function
On Thu, Jun 12, 2014 at 02:34:10PM -0500, Andy Gross wrote: > This patch removes the chip select function. Chip select should instead be > supported using GPIOs, defining the DT entry "cs-gpios", and letting the SPI > core assert/deassert the chip select as it sees fit. Why? signature.asc Description: Digital signature
Re: [Patch v2 3/3] spi: qup: Add support for v1.1.1
On Thu, Jun 12, 2014 at 02:34:12PM -0500, Andy Gross wrote: > This patch adds support for v1.1.1 of the SPI QUP controller. Applied, thanks. signature.asc Description: Digital signature
[PATCH] thunderbolt: select CRC32 in Kconfig
We use __crc32c_le in ctl.c. So make sure that the dependency is there. Reported-by: kbuild test robot Signed-off-by: Andreas Noever --- drivers/thunderbolt/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thunderbolt/Kconfig b/drivers/thunderbolt/Kconfig index 5aab79b..c121acc 100644 --- a/drivers/thunderbolt/Kconfig +++ b/drivers/thunderbolt/Kconfig @@ -1,6 +1,7 @@ menuconfig THUNDERBOLT tristate "Thunderbolt support for Apple devices" depends on PCI + select CRC32 help Cactus Ridge Thunderbolt Controller driver This driver is required if you want to hotplug Thunderbolt devices on -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] spi: sh-msiof: Add more register documentation
On Fri, Jun 20, 2014 at 12:16:16PM +0200, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 3/5] spi: sh-msiof: Improve transfer error handling
On Fri, Jun 20, 2014 at 12:16:18PM +0200, Geert Uytterhoeven wrote: > - Add a timeout when waiting for the transfer complete interrupt, > - If sh_msiof_spi_stop() fails, there's no need to clear IER, as the > interrupt handler has already done that, > - Propagate transfer failures in sh_msiof_transfer_one(). Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 4/5] spi: sh-msiof: Refactor sh_msiof_transfer_one()
On Fri, Jun 20, 2014 at 12:16:19PM +0200, Geert Uytterhoeven wrote: > - Move buffer pointer and length setup to the top, > - Make unsigned values unsigned, > - Loop over words and increment pointers instead of recalculating them, > which allows to kill bytes_done. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 2/5] spi: sh-msiof: Extract sh_msiof_spi_{start,stop}() helpers
On Fri, Jun 20, 2014 at 12:16:17PM +0200, Geert Uytterhoeven wrote: > Based on an old patch by Guennadi Liakhovetski Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 5/5] spi: sh-msiof: Add DMA support
On Fri, Jun 20, 2014 at 12:16:20PM +0200, Geert Uytterhoeven wrote: > Add DMA support to the MSIOF driver using platform data. This doesn't apply against current code, can you please check and resend? signature.asc Description: Digital signature
Re: [PATCH] net/wireless/brcm80211/brcmfmac: Make return type reflect actual semantics
On 06/20/14 23:32, Rasmus Villemoes wrote:
Applying ++ to a bool is equivalent to setting it true, regardless of
its initial value (bools are not uint1_t). Hence the function
wl_get_vif_state_all can only ever return true/false. The only
in-tree caller uses its return value as a boolean. So update its
return type, and since the list traversal and bit testing have no side
effects, just return true immediately.
Hi Rasmus,
At the moment the function is indeed only used to determine whether any
vif is in connected state. I am ok with your patch if you would also
rename the function to brcmf_get_vif_state_any(). You may add
'Reviewed-by: Arend van Spriel ' to the patch.
Regards,
Arend
Signed-off-by: Rasmus Villemoes
---
Notes:
Alternatively, if the function is supposed to return a count, the
one-line fix would be
- bool result = 0;
+ u32 result = 0;
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 7 +++
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.h | 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index d8fa276..ec5f8c5 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -5625,16 +5625,15 @@ enum nl80211_iftype brcmf_cfg80211_get_iftype(struct
brcmf_if *ifp)
return wdev->iftype;
}
-u32 wl_get_vif_state_all(struct brcmf_cfg80211_info *cfg, unsigned long state)
+bool wl_get_vif_state_all(struct brcmf_cfg80211_info *cfg, unsigned long state)
{
struct brcmf_cfg80211_vif *vif;
- bool result = 0;
list_for_each_entry(vif,&cfg->vif_list, list) {
if (test_bit(state,&vif->sme_state))
- result++;
+ return true;
}
- return result;
+ return false;
}
static inline bool vif_event_equals(struct brcmf_cfg80211_vif_event *event,
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.h
b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.h
index 283c525..c702e4e 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.h
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.h
@@ -477,7 +477,7 @@ const struct brcmf_tlv *
brcmf_parse_tlvs(const void *buf, int buflen, uint key);
u16 channel_to_chanspec(struct brcmu_d11inf *d11inf,
struct ieee80211_channel *ch);
-u32 wl_get_vif_state_all(struct brcmf_cfg80211_info *cfg, unsigned long state);
+bool wl_get_vif_state_all(struct brcmf_cfg80211_info *cfg, unsigned long
state);
void brcmf_cfg80211_arm_vif_event(struct brcmf_cfg80211_info *cfg,
struct brcmf_cfg80211_vif *vif);
bool brcmf_cfg80211_vif_event_armed(struct brcmf_cfg80211_info *cfg);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: palmas: Fix SMPS enable/disable/is_enabled
On Fri, Jun 20, 2014 at 12:26:23PM -0500, Nishanth Menon wrote: > We use regmap regulator ops to enable/disable and check if regulator > is enabled for various SMPS. However, these depend on valid > enable_reg, enable_mask and enable_value in regulator descriptor. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 1/1] regulator: ltc3589: Staticize ltc3589_reg_defaults
On Tue, Jun 10, 2014 at 12:04:53PM +0530, Sachin Kamat wrote: > 'ltc3589_reg_defaults' is local to this file. Make it static. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCHv2 0/2] regulator: of: Add support for pasing regulator suspend state
On Tue, Jun 17, 2014 at 09:39:51AM +0900, Chanwoo Choi wrote: > Hi Mark, > > Could you please review this patchset? Please don't send contentless, top posted pings. It's just more e-mail to read. signature.asc Description: Digital signature
Re: [PATCH v5] iio: dac: mcp4902/mcp4912/mcp4922 dac driver
On 15/06/14 22:17, Michael Welling wrote:
This patch provides an iio device driver for the Microchip
MCP49x2 series DACs.
Normally this lot goes below the --- inorder that it doesn't then lead
to really long commit messages in git. Anyhow, I just dropped this stuff
during the commit. It's enough to have it in the list archives.
v5:
- Removes wildcard naming in filename and variables.
- Switches to using iio_device_register/unregister to avoid race condition.
- Removes --- around help in the Kconfig entry.
- Removes unused variable.
- Adds checking for val2 in write_raw function.
v4:
- Removes use of old IIO_ST macro.
- Moves mosi variable to the state struct.
- Removes default vref of 2.5v.
v3:
- Removes MCP49X2_RES_MASK and uses GENMASK directly.
- Switch from using address to channel in functions.
v2:
- Switched to using GENMASK instead of creating a mask directly.
- Switched from using address to channel.
- Removed unnecessary feilds from channel macro.
- Made SPI buffer cachline aligned.
- Removed some uncessary bounds checking.
- Report -EINVAL when writing a value beyond the range to DAC.
- Switched to devm_iio_device_alloc.
- Created a constant for the number of channels.
- Switched to devm_ioo_device_register.
Signed-off-by: Michael Welling
Applied to the togreg branch of iio.git. Note this is initially pushed
out as testing to allow the autobuilders to do there work before I commit
to not rebasing the tree!
Thanks for your hard work on this. It's a nice little driver!
Jonathan
---
drivers/iio/dac/Kconfig | 10 +++
drivers/iio/dac/Makefile |1 +
drivers/iio/dac/mcp4922.c | 216 +
3 files changed, 227 insertions(+)
create mode 100644 drivers/iio/dac/mcp4922.c
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index f378ca8..f278eff 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -163,4 +163,14 @@ config MCP4725
To compile this driver as a module, choose M here: the module
will be called mcp4725.
+config MCP4922
+ tristate "MCP4902, MCP4912, MCP4922 DAC driver"
+ depends on SPI
+ help
+ Say yes here to build the driver for the Microchip MCP4902
+ MCP4912, and MCP4922 DAC devices.
+
+ To compile this driver as a module, choose M here: the module
+ will be called mcp4922.
+
endmenu
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index bb84ad6..1010764 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_AD5686) += ad5686.o
obj-$(CONFIG_AD7303) += ad7303.o
obj-$(CONFIG_MAX517) += max517.o
obj-$(CONFIG_MCP4725) += mcp4725.o
+obj-$(CONFIG_MCP4922) += mcp4922.o
diff --git a/drivers/iio/dac/mcp4922.c b/drivers/iio/dac/mcp4922.c
new file mode 100644
index 000..92cf4ca
--- /dev/null
+++ b/drivers/iio/dac/mcp4922.c
@@ -0,0 +1,216 @@
+/*
+ * mcp4922.c
+ *
+ * Driver for Microchip Digital to Analog Converters.
+ * Supports MCP4902, MCP4912, and MCP4922.
+ *
+ * Copyright (c) 2014 EMAC Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MCP4922_NUM_CHANNELS 2
+
+enum mcp4922_supported_device_ids {
+ ID_MCP4902,
+ ID_MCP4912,
+ ID_MCP4922,
+};
+
+struct mcp4922_state {
+ struct spi_device *spi;
+ unsigned int value[MCP4922_NUM_CHANNELS];
+ unsigned int vref_mv;
+ struct regulator *vref_reg;
+ u8 mosi[2] cacheline_aligned;
+};
+
+#define MCP4922_CHAN(chan, bits) { \
+ .type = IIO_VOLTAGE,\
+ .output = 1,\
+ .indexed = 1, \
+ .channel = chan,\
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+ .scan_type = { \
+ .sign = 'u',\
+ .realbits = (bits), \
+ .storagebits = 16, \
+ .shift = 12 - (bits), \
+ }, \
+}
+
+static int mcp4922_spi_write(struct mcp4922_state *state, u8 addr, u32 val)
+{
+ state->mosi[1] = val & 0xff;
+ state->mosi[0] = (addr == 0) ? 0x00 : 0x80;
+
Re: SmPL for automatic request_firmware_nowait() conversion
Luis R. Rodriguez : > I was just porting over an ethernet driver [0] to use > request_firmware_nowait() > since firmware loading seems can take over a minute on one device, while > at it I noticed no other ethernet drivers yet use this API so figure > this may be a trend coming if devices are getting as complex as cxgb4. > The cxgb4 driver happens to even use the firmware API 3 times! There should be no problem for the firmware requests issued through ethtool in cxgb4. [...] > netdev: how worthy is this effort? Biased comment below :o) I'm wondering the benefit of automatic API changes when it could be argued that the symptoms call for driver dependant code rework. The 60 seconds delay is kind of a pavlovian signal: one can bet that the driver includes a request_firmware in its probe method. So does cxgb4. I still believe in the old school "request firmware from net_device_ops.open". I've been happy with it since f1e02ed109df5f99abf942b8ccc99960cb09dd38. This kind of rework may not be trivial for cxgb4. Please get code tested on real hardware (modular/monolithic build, with/without firmware, etc.) as I won't argue against your crusade for cxgb4. Asynchronous firmware loading provides a rather nice high level API but it's imho not the essence of network devices firmware loading problems. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] iio: documentation: Added documentation for rotation from north usage attributes
On 16/06/14 23:30, Reyad Attiyat wrote: Added documentation for the sysfs attributes added by the rotation from north usage attributes. Signed-off-by: Reyad Attiyat Nearly there, but I'd prefer a slight reorganization of the docs. See below. --- Documentation/ABI/testing/sysfs-bus-iio | 79 - 1 file changed, 78 insertions(+), 1 deletion(-) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index a9757dc..2837fd9 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -260,6 +260,10 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_scale +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_scale +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_tilt_comp_scale +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale KernelVersion:2.6.35 @@ -447,6 +451,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_thresh_rising_en What: /sys/.../iio:deviceX/events/in_magn_y_thresh_falling_en What: /sys/.../iio:deviceX/events/in_magn_z_thresh_rising_en What: /sys/.../iio:deviceX/events/in_magn_z_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en @@ -492,6 +504,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_roc_rising_en What: /sys/.../iio:deviceX/events/in_magn_y_roc_falling_en What: /sys/.../iio:deviceX/events/in_magn_z_roc_rising_en What: /sys/.../iio:deviceX/events/in_magn_z_roc_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_roc_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_roc_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_roc_rising_en @@ -538,6 +558,14 @@ What: /sys/.../events/in_magn_y_raw_thresh_rising_value What: /sys/.../events/in_magn_y_raw_thresh_falling_value What: /sys/.../events/in_magn_z_raw_thresh_rising_value What: /sys/.../events/in_magn_z_raw_thresh_falling_value +What: /sys/.../events/in_rot_from_north_magnetic_raw_thresh_rising_value +What: /sys/.../events/in_rot_from_north_magnetic_raw_thresh_falling_value +What: /sys/.../events/in_rot_from_north_true_raw_thresh_rising_value +What: /sys/.../events/in_rot_from_north_true_raw_thresh_falling_value +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_rising_value +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_falling_value +What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_rising_value +What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_falling_value What: /sys/.../events/in_voltageY_supply_raw_thresh_rising_value What: /
[PATCH v10 3/5] ARM: sunxi: Add pins for IR controller on A20 to dtsi
This patch adds pins for two IR controllers on A20
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
arch/arm/boot/dts/sun7i-a20.dtsi | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 01e9466..656d7d3 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -738,6 +738,20 @@
allwinner,drive = <2>;
allwinner,pull = <0>;
};
+
+ ir0_pins_a: ir0@0 {
+ allwinner,pins = "PB3","PB4";
+ allwinner,function = "ir0";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ ir1_pins_a: ir1@0 {
+ allwinner,pins = "PB22","PB23";
+ allwinner,function = "ir1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
};
timer@01c20c00 {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 0/5] ARM: sunxi: Add support for consumer infrared devices
This patch introduces Consumer IR(CIR) support for sunxi boards. This is based on Alexsey Shestacov's work based on the original driver supplied by Allwinner. Signed-off-by: Alexander Bersenev Signed-off-by: Alexsey Shestacov --- Changes since version 1: - Fix timer memory leaks - Fix race condition when driver unloads while interrupt handler is active - Support Cubieboard 2(need testing) Changes since version 2: - More reliable keydown events - Documentation fixes - Rename registers accurding to A20 user manual - Remove some includes, order includes alphabetically - Use BIT macro - Typo fixes Changes since version 3: - Split the patch on smaller parts - More documentation fixes - Add clock-names in DT - Use devm_clk_get function to get the clocks - Removed gpios property from ir's DT - Changed compatible from allwinner,sunxi-ir to allwinner,sun7i-a20-ir in DT - Use spin_lock_irq instead spin_lock_irqsave in interrupt handler - Add myself in the copyright ;) - Coding style and indentation fixes Changes since version 4: - Try to fix indentation errors by sending patches with git send-mail Changes since version 5: - More indentation fixes - Make patches pass checkpatch with --strict option - Replaced magic numbers with defines(patch by Priit Laes) - Fixed oops on loading(patch by Hans de Goede) Changes since version 6: - Removed constants from code - Better errrors handling on loading - Renamed sunxi-ir.c to sunxi-cir.c - Changed description of second commit - Order entries in dts and dtsi by register address - Code style fixes Changes since version 7: - Removed a couple of blank lines in code - Delay interrupts init until we are ready to handle them - Increased the reported duration of each pulse by one - Refactored defines Changes since version 8: - Split the DT patch to three - Code style fixes Changes since version 9: - Rebase patches on 3.16-rc1 Alexander Bersenev (5): ARM: sunxi: Add documentation for sunxi consumer infrared devices [media] rc: add sunxi-ir driver ARM: sunxi: Add pins for IR controller on A20 to dtsi ARM: sunxi: Add IR controllers on A20 to dtsi ARM: sunxi: Enable IR controller on cubieboard 2 and cubietruck in dts .../devicetree/bindings/media/sunxi-ir.txt | 23 ++ arch/arm/boot/dts/sun7i-a20-cubieboard2.dts|6 + arch/arm/boot/dts/sun7i-a20-cubietruck.dts |6 + arch/arm/boot/dts/sun7i-a20.dtsi | 32 ++ drivers/media/rc/Kconfig | 10 + drivers/media/rc/Makefile |1 + drivers/media/rc/sunxi-cir.c | 318 7 files changed, 396 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/sunxi-ir.txt create mode 100644 drivers/media/rc/sunxi-cir.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 4/5] ARM: sunxi: Add IR controllers on A20 to dtsi
This patch adds records for two IR controllers on A20
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
arch/arm/boot/dts/sun7i-a20.dtsi | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 656d7d3..1782375 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -785,6 +785,24 @@
status = "disabled";
};
+ ir0: ir@01c21800 {
+ compatible = "allwinner,sun7i-a20-ir";
+ clocks = <&apb0_gates 6>, <&ir0_clk>;
+ clock-names = "apb", "ir";
+ interrupts = <0 5 4>;
+ reg = <0x01c21800 0x40>;
+ status = "disabled";
+ };
+
+ ir1: ir@01c21c00 {
+ compatible = "allwinner,sun7i-a20-ir";
+ clocks = <&apb0_gates 7>, <&ir1_clk>;
+ clock-names = "apb", "ir";
+ interrupts = <0 6 4>;
+ reg = <0x01c21c00 0x40>;
+ status = "disabled";
+ };
+
sid: eeprom@01c23800 {
compatible = "allwinner,sun7i-a20-sid";
reg = <0x01c23800 0x200>;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 5/5] ARM: sunxi: Enable IR controller on cubieboard 2 and cubietruck in dts
This patch enables two IR devices in dts:
- One IR device physically found on Cubieboard 2
- One IR device physically found on Cubietruck
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts |6 ++
arch/arm/boot/dts/sun7i-a20-cubietruck.dts |6 ++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index a5ad945..a70f0b4 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -66,6 +66,12 @@
};
};
+ ir0: ir@01c21800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir0_pins_a>;
+ status = "okay";
+ };
+
uart0: serial@01c28000 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index b87fea9..96639d5 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -100,6 +100,12 @@
status = "okay";
};
+ ir0: ir@01c21800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir0_pins_a>;
+ status = "okay";
+ };
+
uart0: serial@01c28000 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 2/5] [media] rc: add sunxi-ir driver
This patch adds driver for sunxi IR controller.
It is based on Alexsey Shestacov's work based on the original driver
supplied by Allwinner.
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
drivers/media/rc/Kconfig | 10 ++
drivers/media/rc/Makefile|1 +
drivers/media/rc/sunxi-cir.c | 318 ++
3 files changed, 329 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/rc/sunxi-cir.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 8fbd377..9427fad 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -343,4 +343,14 @@ config RC_ST
If you're not sure, select N here.
+config IR_SUNXI
+tristate "SUNXI IR remote control"
+depends on RC_CORE
+depends on ARCH_SUNXI
+---help---
+ Say Y if you want to use sunXi internal IR Controller
+
+ To compile this driver as a module, choose M here: the module will
+ be called sunxi-ir.
+
endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index f8b54ff..9ee9ee7 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
obj-$(CONFIG_IR_IGUANA) += iguanair.o
obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
obj-$(CONFIG_RC_ST) += st_rc.o
+obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
obj-$(CONFIG_IR_IMG) += img-ir/
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
new file mode 100644
index 000..5971b69
--- /dev/null
+++ b/drivers/media/rc/sunxi-cir.c
@@ -0,0 +1,318 @@
+/*
+ * Driver for Allwinner sunXi IR controller
+ *
+ * Copyright (C) 2014 Alexsey Shestacov
+ * Copyright (C) 2014 Alexander Bersenev
+ *
+ * Based on sun5i-ir.c:
+ * Copyright (C) 2007-2012 Daniel Wang
+ * Allwinner Technology Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define SUNXI_IR_DEV "sunxi-ir"
+
+/* Registers */
+/* IR Control */
+#define SUNXI_IR_CTL_REG 0x00
+/* Global Enable */
+#define REG_CTL_GENBIT(0)
+/* RX block enable */
+#define REG_CTL_RXEN BIT(1)
+/* CIR mode */
+#define REG_CTL_MD (BIT(4) | BIT(5))
+
+/* Rx Config */
+#define SUNXI_IR_RXCTL_REG0x10
+/* Pulse Polarity Invert flag */
+#define REG_RXCTL_RPPI BIT(2)
+
+/* Rx Data */
+#define SUNXI_IR_RXFIFO_REG 0x20
+
+/* Rx Interrupt Enable */
+#define SUNXI_IR_RXINT_REG0x2C
+/* Rx FIFO Overflow */
+#define REG_RXINT_ROI_EN BIT(0)
+/* Rx Packet End */
+#define REG_RXINT_RPEI_EN BIT(1)
+/* Rx FIFO Data Available */
+#define REG_RXINT_RAI_EN BIT(4)
+
+/* Rx FIFO available byte level */
+#define REG_RXINT_RAL(val)(((val) << 8) & (GENMASK(11, 8)))
+
+/* Rx Interrupt Status */
+#define SUNXI_IR_RXSTA_REG0x30
+/* RX FIFO Get Available Counter */
+#define REG_RXSTA_GET_AC(val) (((val) >> 8) & (GENMASK(5, 0)))
+/* Clear all interrupt status value */
+#define REG_RXSTA_CLEARALL0xff
+
+/* IR Sample Config */
+#define SUNXI_IR_CIR_REG 0x34
+/* CIR_REG register noise threshold */
+#define REG_CIR_NTHR(val)(((val) << 2) & (GENMASK(7, 2)))
+/* CIR_REG register idle threshold */
+#define REG_CIR_ITHR(val)(((val) << 8) & (GENMASK(15, 8)))
+
+/* Hardware supported fifo size */
+#define SUNXI_IR_FIFO_SIZE16
+/* How many messages in FIFO trigger IRQ */
+#define TRIGGER_LEVEL 8
+/* Required frequency for IR0 or IR1 clock in CIR mode */
+#define SUNXI_IR_BASE_CLK 800
+/* Frequency after IR internal divider */
+#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
+/* Sample period in ns */
+#define SUNXI_IR_SAMPLE (10ul / SUNXI_IR_CLK)
+/* Noise threshold in samples */
+#define SUNXI_IR_RXNOISE 1
+/* Idle Threshold in samples */
+#define SUNXI_IR_RXIDLE 20
+/* Time after which device stops sending data in ms */
+#define SUNXI_IR_TIMEOUT 120
+
+struct sunxi_ir {
+ spinlock_t ir_lock;
+ struct rc_dev *rc;
+ void __iomem*base;
+ int irq;
+ struct clk *clk;
+ struct clk *apb_clk;
+ const char *map_name;
+};
+
+static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
+{
+ unsigned long status;
+ unsigned char dt;
+ unsigned int cnt, rc;
+ struct sunxi_ir *ir = dev_id;
+ DEFINE_IR_RAW_EVENT(rawir);
+
+ spin_lock(&ir->ir_lock);
[PATCH v10 1/5] ARM: sunxi: Add documentation for sunxi consumer infrared devices
This patch adds documentation for Device-Tree bindings for sunxi IR
controller.
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
.../devicetree/bindings/media/sunxi-ir.txt | 23
1 files changed, 23 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/sunxi-ir.txt
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
new file mode 100644
index 000..014dd8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -0,0 +1,23 @@
+Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
+
+Required properties:
+- compatible : should be "allwinner,sun7i-a20-ir";
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : should contain "apb" and "ir" entries;
+- interrupts : should contain IR IRQ number;
+- reg : should contain IO map address for IR.
+
+Optional properties:
+- linux,rc-map-name : Remote control map name.
+
+Example:
+
+ir0: ir@01c21800 {
+ compatible = "allwinner,sun7i-a20-ir";
+ clocks = <&apb0_gates 6>, <&ir0_clk>;
+ clock-names = "apb", "ir";
+ interrupts = <0 5 1>;
+ reg = <0x01C21800 0x40>;
+ linux,rc-map-name = "rc-rc6-mce";
+};
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] iio: hid-sensor-magn-3d: Add support for rotation from north usage attributes
On 16/06/14 23:30, Reyad Attiyat wrote:
Added the ability for this driver to scan for a range of hid usage attributes.
This allows for dynamic creation of iio channels such as rotation from north
and/or magnetic flux axises (X, Y, Z).
Signed-off-by: Reyad Attiyat
Hi Reyad,
I'm afraid I hadn't taken as close a look at this as I should for previous
versions. There are some nasty bugs introduced by your refactoring.
The fundamental approach is fine, but you've moved more things than
make sense in some cases.
With hind sight perhaps it would have been possible to break this patch
up into a series of small easily reviewed steps.
Anyhow, take a hard look at the error paths in the code as someone of them
are thorougly broken. The channel setup function does an awful lot more
than setup the channels and it should not do so. Moving other stuff in
there makes the code harder to follow and is responsible for at least
a few bugs that otherwise would not have occured.
Thanks,
Jonathan
---
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 394 +-
1 file changed, 266 insertions(+), 128 deletions(-)
diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index 41cf29e..73e1272 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -35,6 +35,10 @@ enum magn_3d_channel {
CHANNEL_SCAN_INDEX_X,
CHANNEL_SCAN_INDEX_Y,
CHANNEL_SCAN_INDEX_Z,
+ CHANNEL_SCAN_INDEX_NORTH_MAGN,
+ CHANNEL_SCAN_INDEX_NORTH_TRUE,
+ CHANNEL_SCAN_INDEX_NORTH_MAGN_TILT_COMP,
+ CHANNEL_SCAN_INDEX_NORTH_TRUE_TILT_COMP,
MAGN_3D_CHANNEL_MAX,
};
@@ -42,63 +46,47 @@ struct magn_3d_state {
struct hid_sensor_hub_callbacks callbacks;
struct hid_sensor_common common_attributes;
struct hid_sensor_hub_attribute_info magn[MAGN_3D_CHANNEL_MAX];
- u32 magn_val[MAGN_3D_CHANNEL_MAX];
+ u32 *magn_val_addr[MAGN_3D_CHANNEL_MAX];
+ u32 *iio_val;
int scale_pre_decml;
int scale_post_decml;
int scale_precision;
int value_offset;
};
-static const u32 magn_3d_addresses[MAGN_3D_CHANNEL_MAX] = {
- HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS,
- HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS,
- HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS
-};
-/* Channel definitions */
-static const struct iio_chan_spec magn_3d_channels[] = {
- {
- .type = IIO_MAGN,
- .modified = 1,
- .channel2 = IIO_MOD_X,
- .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
- .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
- BIT(IIO_CHAN_INFO_SCALE) |
- BIT(IIO_CHAN_INFO_SAMP_FREQ) |
- BIT(IIO_CHAN_INFO_HYSTERESIS),
- .scan_index = CHANNEL_SCAN_INDEX_X,
- }, {
- .type = IIO_MAGN,
- .modified = 1,
- .channel2 = IIO_MOD_Y,
- .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
- .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
- BIT(IIO_CHAN_INFO_SCALE) |
- BIT(IIO_CHAN_INFO_SAMP_FREQ) |
- BIT(IIO_CHAN_INFO_HYSTERESIS),
- .scan_index = CHANNEL_SCAN_INDEX_Y,
- }, {
- .type = IIO_MAGN,
- .modified = 1,
- .channel2 = IIO_MOD_Z,
- .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
- .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
- BIT(IIO_CHAN_INFO_SCALE) |
- BIT(IIO_CHAN_INFO_SAMP_FREQ) |
- BIT(IIO_CHAN_INFO_HYSTERESIS),
- .scan_index = CHANNEL_SCAN_INDEX_Z,
+/* Find index into magn_3d_state magn[] and magn_val_addr[] from HID Usage */
+static int magn_3d_usage_id_to_chan_index(unsigned usage_id){
+ int offset;
+
+ switch (usage_id) {
+ case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS:
+ offset = CHANNEL_SCAN_INDEX_X;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS:
+ offset = CHANNEL_SCAN_INDEX_Y;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS:
+ offset = CHANNEL_SCAN_INDEX_Z;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_COMP_MAGN_NORTH:
+ offset = CHANNEL_SCAN_INDEX_NORTH_MAGN_TILT_COMP;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_COMP_TRUE_NORTH:
+ offset = CHANNEL_SCAN_INDEX_NORTH_TRUE_TILT_COMP;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_MAGN_NORTH:
+ offset = CHANNEL_SCAN_INDEX_NORTH_MAGN;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_TRUE_NORTH:
+ offset = CHANNEL_SCAN_INDEX_NORTH_TRUE;
+ break;
+ default:
+ offset = -EINVAL;
+ break;
}
-};
-/* A
Re: [PATCH 4/8] iio: Add support for DA9150 GPADC
On 16/06/14 16:58, Opensource [Adam Thomson] wrote: On June 15, 2014 21:19, Jonathon Cameron wrote: Hi Adam Reasonably clean code, but the _ channels stuff doesn't comply with the ABI and is rather confusing. To be honest I did debate this in my head for a while. The reason I went with the current approach was to make the driver channel layout match that of the datasheet for the device. Sounds like it wasn't the correct direction though. If it really does make sense to allow reading these channels at different ranges (presumably to enhance the effective adc resolution) then we need to control this via existing ABIs. Controlling it via scale with a range attribute if required (read only but changes with whatever the scale attribute it set to). Yes, with smaller range then you get a better degree of accuracy. Ok, will have a look at this and see if I can improve things based on your comments. Often, for slow parts at least it makes little sense to have provide software support for variable input ranges. Looking at what is covered, is it the case that only one option will make sense for a given hardware setup? (cover the required range and nothing more). If so, perhaps this wants to go into the device tree or similar? Possibly. Having read your comments further on though, and given that it seems reasonable to use the range/scale attribute to choose the resolution, I'd prefer to opt for that approach (seems more flexible). Perhaps, but if the reason for these differing ranges is that they tend to be wired to lines that have well defined voltage ranges, then I'd move it into setup data. Leads to a cleaner driver. Flexibility is good, but only if actually helps anyone! Please get rid of excess white space and comments that just tell you something obvious about the code following them. Preferably I'd like to keep it this way as I think it makes the code easier to read, but if you're dead against it then I'll remove them. The issue here is about making kernel review as easy as possible. That often involves making code (and particularly comments) conform to somewhat arbitrary rules and conventions. Just makes the reviewer/maintainers life somewhat easier. You'll also probably get follow up patches removing all this stuff on the basis of kernel style soon after we merge the driver anyway and those just get irritating ;) Linear in the coeeficients, so fine for raw output with a scale and offset. Ok will have a look at re-working this as per your comment. Ah, so here is your reasoning behind the 'interesting' underscore channels. This is just doing different range checks on the channel? If so allow one at a time and provide a writable scale info_mask element to control which is used.. Looks like there are only thes two channels doing this, so shouldn't be too hard to support it via more conventional means. The GPIO, VBUS and VSYS related channels provide different ranges. I guess they should all follow the same approach for implementing this alternate range. So I will assume that for the 'repeat' channels where the same raw value is provided on both the _ and non _ channels only one channel should be provided. Definitely. Don't use the |=, just = and you can't avoid assigning reg above. Actually, it's not complex enough that you couldn't just do it directly into the write function and skip this local variable. Ok fine. Will update to tidy up. Unlock first, then check for error. Yep. Makes sense. Will update. The mixture of having defs here for the shift. + /* MSBs - 8 bits */ + result |= result_regs[0] << 2; and not here is inconsistent. I honestly don't mind which way, but just use one style. You could just use an endian conversion and shift the combined 16bit result Fair point. Will make this cleaner. It very rarely makes sense to provide both raw and processed interfaces. If the transform is nasty and non linear then userspace won't have the info to do anything with it. If the transform is linear, then provide scale and offset and let userspace perform the computation. The charger module uses certain channels for its readings, and to me it makes more sense for that calculation to be done by the GPADC. However having looked at the inkern.c framework code it looks like if you request a processed channel and it's doesn't provide that feature, then the code drops to linear scaling if possible to provide the processed value. I take it this is the preferred approach then? Yup. Saves on replicating code. Mostly the raw access stuff is there for consistency with buffered access (where speed matters and we may or may not want to convert to real units). So you should provide the information to do the scaling anyway, so just let the core code handle it for you. Just thought it was more consistent to see the calculation using dedicated functions (processed channel approach). Get rid of this comment and any other ones that don't add any actual i
Re: [PATCH 3/8] iio: of_iio_channel_get_by_name() returns non-null pointers for error legs
On 15/06/14 21:20, Jonathan Cameron wrote:
On 11/06/14 12:11, Adam Thomson wrote:
Currently in the inkern.c code for IIO framework, the function
of_iio_channel_get_by_name() will return a non-NULL pointer when
it cannot find a channel using of_iio_channel_get() and when it
tries to search for 'io-channel-ranges' property and fails. This
is incorrect behaviour as the function which calls this expects
a NULL pointer for failure. This patch rectifies the issue.
Signed-off-by: Adam Thomson
Hi Adam,
Good find. I've only recently sent a pull request for fixes upstream,
so I'll pick this up in a day or so once that has gone.
Applied to the fixes-togreg branch of iio.git and cc'd to stable.
Thanks,
Jonathan
J
---
drivers/iio/inkern.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 0cf5f8e..1e8e94d 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -183,7 +183,7 @@ static struct iio_channel
*of_iio_channel_get_by_name(struct device_node *np,
else if (name && index >= 0) {
pr_err("ERROR: could not get IIO channel %s:%s(%i)\n",
np->full_name, name ? name : "", index);
-return chan;
+return NULL;
}
/*
@@ -193,8 +193,9 @@ static struct iio_channel
*of_iio_channel_get_by_name(struct device_node *np,
*/
np = np->parent;
if (np && !of_get_property(np, "io-channel-ranges", NULL))
-break;
+return NULL;
}
+
return chan;
}
@@ -317,6 +318,7 @@ struct iio_channel *iio_channel_get(struct device *dev,
if (channel != NULL)
return channel;
}
+
return iio_channel_get_sys(name, channel_name);
}
EXPORT_SYMBOL_GPL(iio_channel_get);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG when trying to use deadline iosched in 3.16-rc1
> It seems you're right. I didn't know that parameter could be updated > dynamically. > In that case, adding __init to elv_register was a bad idea because it's no > more > reliable. Could you revert that patch Jens ? I confirm that reverting locally makes the problem go away. Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] mfd: Add support for DA9150 combined charger & fuel-gauge device
On 16/06/14 14:12, Opensource [Adam Thomson] wrote: On Sun, Jun 15, 2014 at 20:49, Jonathan Cameron wrote: Hi Adam, Some general comments inline. It's been a while since I've looked at any particularly similar parts, but it seems to me that a lot of indirection gets added here that if anything makes the codes slightly harder to follow... Feel free to disagree with me though! Will do :) To my mind all these wrappers add nothing significant so you might as well just call da9150->read_dev etc directly. Also, what are the read_qif and write_qif for? They don't seem to be used anywhere. read_qif and write_qif are for the Fuel-Gauge functionality of the chip. The associated driver will be submitted after acceptance of initial driver code, and will make use of these functions. Ideally drop these for now and bring them in as a precursor patch in the series that introduces them being used. The wrappers automatically choose the correct client to use (QIF uses a different slave address to the main chip one). Means the child drivers only need to pass through the da9150 struct and the rest is dealt with underneath. The only real reason I can see for these wrappers is because you want to hide the struct da9150 contents from the children of the mfd. As you aren't doing that, you might as well drop these in favour of direct calls to regmap_read and friends. As I have a need to pass through the main da9150 struct point for the aforementioned wrappers, it seemed cleaner and more consistent to have wrappers for these as well, which did the job of regmap access. Means all HW access uses the same kind of approach, and all sub-devices just need a point to the main da9150 struct to be able to use the functions. I'll continue my tirade against obvious comments. Wrong format and adds nothing to what is here as init and exit functions are clearly doing what their name suggests (it's one of my pet hates ;) I agree the comment doesn't add much in terms of description but for me it breaks up the code to make it easier to follow. They really don't make it significantly easier to follow and after a few cycles of the driver being patched with new stuff etc, they tend to become actively misleading. However if I get an overwhelming hatred for this I can change it. Also, I know the rule regarding single/multiple line comments but here again I feel it helps separate the code and makes it easier to read. I'll leave it up to the other maintainers to say they don't mind. But for IIO please keep strictly to the style (including all the unwritten bits ;) As a general good practice point, I'd rather that the driver supported more than one instance of the chip.. Hence you'd take a copy of da9150_devs to use here. I guess it is relatively unlikely with one of these, but you never know ;) Have followed the general methods for MFD here, and a number of drivers take the same approach. Also, I think it would be undesirable to have multiple charger chips of the same type in one platform. I agree generally it's best to support multiple instances, but here I don't think we should. You are a brave man to tell your customers what to do. If some crazy person does use multiple of these chips on a device you get to deal with the inevitable question of why doesn't it work ;) Why does this need it's own file? Does the DA9150 support any other interfaces? Yes, the DA9150 also has a SPI interface. At present the plan is to just add I2C support for now, but in the future we may add SPI support, so have written the code with this in mind. Ah, I didn't find that from the details I could find via google. In that case fair enough. Why the indirection? The da9150 only supports i2c as far as I can see. As per my last comment. I'd roll this into one line and not bother with the local variable... Fair enough but I think this keeps the code cleaner, and to me it makes sense for the actual logic to be in core file as that's interface agnostic. Drop comments on things that are self-evident. Also these are one line comments so should be using the single line comment syntax. As per my previous comment I think it just helps to break up the code and makes it more readable. Will change it though if the general consensus is to remove it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Revert "block: add __init to elv_register"
This reverts commit b5097e956a4d
Adding __init to elv_register makes it unreliable when updating
/sys/block/sdX/queue/scheduler at runtime
Reported-by: Damien Wyart
Cc: Damien Wyart
Cc: Jens Axboe
Signed-off-by: Fabian Frederick
---
block/elevator.c | 2 +-
include/linux/elevator.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/elevator.c b/block/elevator.c
index 34bded1..24c28b6 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -825,7 +825,7 @@ void elv_unregister_queue(struct request_queue *q)
}
EXPORT_SYMBOL(elv_unregister_queue);
-int __init elv_register(struct elevator_type *e)
+int elv_register(struct elevator_type *e)
{
char *def = "";
diff --git a/include/linux/elevator.h b/include/linux/elevator.h
index e2a6bd7..45a9147 100644
--- a/include/linux/elevator.h
+++ b/include/linux/elevator.h
@@ -143,7 +143,7 @@ extern void elv_drain_elevator(struct request_queue *);
* io scheduler registration
*/
extern void __init load_default_elevator_module(void);
-extern int __init elv_register(struct elevator_type *);
+extern int elv_register(struct elevator_type *);
extern void elv_unregister(struct elevator_type *);
/*
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[for-next][PATCH] tracing: Add __field_struct macro for TRACE_EVENT()
Updates to the RAS tracepoints found that the __field() macro has a bug
in it where you can not use it with structures. It only works with
primitives. This is because of an added check to determine if the field
is signed or not.
A new macro is created called __field_struct() that can be used to save
structured data directly in the tracepoint and not have to settle for
storing as an array with memcpy.
-- Steve
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next
Head SHA1: 4d4c9cc839a308be3289a361ccba4447ee140552
Steven Rostedt (1):
tracing: Add __field_struct macro for TRACE_EVENT()
include/trace/ftrace.h | 33 ++
samples/trace_events/trace-events-sample.h | 3 ++-
2 files changed, 35 insertions(+), 1 deletion(-)
---
commit 4d4c9cc839a308be3289a361ccba4447ee140552
Author: Steven Rostedt
Date: Tue Jun 17 08:59:16 2014 -0400
tracing: Add __field_struct macro for TRACE_EVENT()
Currently the __field() macro in TRACE_EVENT is only good for primitive
values, such as integers and pointers, but it fails on complex data types
such as structures or unions. This is because the __field() macro
determines if the variable is signed or not with the test of:
(((type)(-1)) < (type)1)
Unfortunately, that fails when type is a structure.
Since trace events should support structures as fields a new macro
is created for such a case called __field_struct() which acts exactly
the same as __field() does but it does not do the signed type check
and just uses a constant false for that answer.
Cc: Tony Luck
Signed-off-by: Steven Rostedt
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 0fd06fef9fac..26b4f2e13275 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -44,6 +44,12 @@
#undef __field_ext
#define __field_ext(type, item, filter_type) typeitem;
+#undef __field_struct
+#define __field_struct(type, item) typeitem;
+
+#undef __field_struct_ext
+#define __field_struct_ext(type, item, filter_type)typeitem;
+
#undef __array
#define __array(type, item, len) typeitem[len];
@@ -122,6 +128,12 @@
#undef __field_ext
#define __field_ext(type, item, filter_type)
+#undef __field_struct
+#define __field_struct(type, item)
+
+#undef __field_struct_ext
+#define __field_struct_ext(type, item, filter_type)
+
#undef __array
#define __array(type, item, len)
@@ -315,9 +327,21 @@ static struct trace_event_functions
ftrace_event_type_funcs_##call = { \
if (ret)\
return ret;
+#undef __field_struct_ext
+#define __field_struct_ext(type, item, filter_type)\
+ ret = trace_define_field(event_call, #type, #item, \
+offsetof(typeof(field), item), \
+sizeof(field.item),\
+0, filter_type); \
+ if (ret)\
+ return ret;
+
#undef __field
#define __field(type, item)__field_ext(type, item, FILTER_OTHER)
+#undef __field_struct
+#define __field_struct(type, item) __field_struct_ext(type, item, FILTER_OTHER)
+
#undef __array
#define __array(type, item, len) \
do {\
@@ -379,6 +403,12 @@ ftrace_define_fields_##call(struct ftrace_event_call
*event_call) \
#undef __field_ext
#define __field_ext(type, item, filter_type)
+#undef __field_struct
+#define __field_struct(type, item)
+
+#undef __field_struct_ext
+#define __field_struct_ext(type, item, filter_type)
+
#undef __array
#define __array(type, item, len)
@@ -550,6 +580,9 @@ static inline notrace int ftrace_get_offsets_##call(
\
#undef __field
#define __field(type, item)
+#undef __field_struct
+#define __field_struct(type, item)
+
#undef __array
#define __array(type, item, len)
diff --git a/samples/trace_events/trace-events-sample.h
b/samples/trace_events/trace-events-sample.h
index 6af373236d73..4b0113f73ee9 100644
--- a/samples/trace_events/trace-events-sample.h
+++ b/samples/trace_events/trace-events-sample.h
@@ -56,7 +56,8 @@
* struct: This defines the way the data will be stored in the ring buffer.
*There are currently two types of elements. __field and __array.
*a __field is broken up into (type, name). Where type can be any
- *type but an array.
+ *primitive type (integer, long or pointer). __field_struct() can
+ *be any static complex data value (struct, union, but not an array).
*For an array. there are three fields. (type, name, size). The
*type of elements in the array, the name of the field
wonga fast loans dear valued customer find the attached file
wonga fast loans dear valued customer find the attached file -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/9] [arch/arm/omap2] replace strict_strto* with kstrto*
Replace obsolete strict_strto call with kstrto calls.
Simplify copy_from_user/strict_strto by using kstrto_from_user
Signed-off-by: Daniel Walter
---
arch/arm/mach-omap2/board-omap3touchbook.c | 2 +-
arch/arm/mach-omap2/mux.c | 22 ++
2 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index 7da48bc..70b904c 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -336,7 +336,7 @@ static int __init early_touchbook_revision(char *p)
if (!p)
return 0;
- return strict_strtoul(p, 10, &touchbook_revision);
+ return kstrtoul(p, 10, &touchbook_revision);
}
early_param("tbr", early_touchbook_revision);
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index fd88ede..9e1b610 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -679,29 +679,19 @@ static ssize_t omap_mux_dbg_signal_write(struct file
*file,
const char __user *user_buf,
size_t count, loff_t *ppos)
{
- char buf[OMAP_MUX_MAX_ARG_CHAR];
struct seq_file *seqf;
struct omap_mux *m;
- unsigned long val;
- int buf_size, ret;
+ u16 val;
+ int ret;
struct omap_mux_partition *partition;
if (count > OMAP_MUX_MAX_ARG_CHAR)
return -EINVAL;
- memset(buf, 0, sizeof(buf));
- buf_size = min(count, sizeof(buf) - 1);
-
- if (copy_from_user(buf, user_buf, buf_size))
- return -EFAULT;
-
- ret = strict_strtoul(buf, 0x10, &val);
+ ret = kstrtou16_from_user(user_buf, count, 0x10, &val);
if (ret < 0)
return ret;
- if (val > 0x)
- return -EINVAL;
-
seqf = file->private_data;
m = seqf->private;
@@ -709,7 +699,7 @@ static ssize_t omap_mux_dbg_signal_write(struct file *file,
if (!partition)
return -ENODEV;
- omap_mux_write(partition, (u16)val, m->reg_offset);
+ omap_mux_write(partition, val, m->reg_offset);
*ppos += count;
return count;
@@ -915,14 +905,14 @@ static void __init omap_mux_set_cmdline_signals(void)
while ((token = strsep(&next_opt, ",")) != NULL) {
char *keyval, *name;
- unsigned long val;
+ u16 val;
keyval = token;
name = strsep(&keyval, "=");
if (name) {
int res;
- res = strict_strtoul(keyval, 0x10, &val);
+ res = kstrtou16(keyval, 0x10, &val);
if (res < 0)
continue;
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/9] replace obsolete strict_strto* calls
Changes since v2: Removed merged patches Changes since v1: Removed [arch/tile] (was merged to tile tree) Added Acked-by Replace all calls to strict_strto* functions with appropriate calls to kstrto*. Remove definition of strict_strto* functions All patches apply against current linux git tree Daniel Walter (9): [arch/arm/omap2] replace strict_strto* with kstrto* [arch/arm/mach-pxa] replace strict_strto call with kstrto [arch/arm/mach-s3c24xx] replace strict_strto* with kstrto* [arch/arm/mach-w90x900] replace obsolete strict_strto [arch/powerpc] replace obsolete strict_strto* calls [arch/x86] replace strict_strto calls [drivers/scsi] replace strict_strto calls [net/sunrpc] replace strict_strto calls [include/linux] remove strict_strto* definitions arch/arm/mach-omap2/board-omap3touchbook.c | 2 +- arch/arm/mach-omap2/mux.c | 22 ++ arch/arm/mach-pxa/balloon3.c | 2 +- arch/arm/mach-pxa/viper.c | 2 +- arch/arm/mach-s3c24xx/mach-jive.c | 2 +- arch/arm/mach-w90x900/cpu.c| 3 ++- arch/powerpc/kernel/setup_64.c | 6 +++--- arch/powerpc/kernel/vio.c | 2 +- arch/powerpc/platforms/pseries/dlpar.c | 4 ++-- arch/powerpc/platforms/pseries/mobility.c | 2 +- arch/x86/kernel/cpu/intel_cacheinfo.c | 4 ++-- arch/x86/kernel/cpu/mcheck/mce.c | 6 +++--- arch/x86/kernel/cpu/mcheck/mce_amd.c | 4 ++-- arch/x86/kvm/mmu_audit.c | 2 +- arch/x86/platform/uv/tlb_uv.c | 2 +- drivers/scsi/pmcraid.c | 4 ++-- drivers/scsi/scsi_sysfs.c | 4 ++-- include/linux/kernel.h | 4 net/sunrpc/addr.c | 16 ++-- net/sunrpc/auth.c | 2 +- net/sunrpc/xprtsock.c | 4 ++-- 21 files changed, 41 insertions(+), 58 deletions(-) -- 2.0.0.526.g5318336 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] [arch/arm/mach-pxa] replace strict_strto call with kstrto
Replace obsolete call to strict_strto with kstrto
Signed-off-by: Daniel Walter
---
arch/arm/mach-pxa/balloon3.c | 2 +-
arch/arm/mach-pxa/viper.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-pxa/balloon3.c b/arch/arm/mach-pxa/balloon3.c
index 43596e0..d897292 100644
--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -90,7 +90,7 @@ int __init parse_balloon3_features(char *arg)
if (!arg)
return 0;
- return strict_strtoul(arg, 0, &balloon3_features_present);
+ return kstrtoul(arg, 0, &balloon3_features_present);
}
early_param("balloon3_features", parse_balloon3_features);
diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
index 41f27f6..de3b080 100644
--- a/arch/arm/mach-pxa/viper.c
+++ b/arch/arm/mach-pxa/viper.c
@@ -769,7 +769,7 @@ static unsigned long viper_tpm;
static int __init viper_tpm_setup(char *str)
{
- return strict_strtoul(str, 10, &viper_tpm) >= 0;
+ return kstrtoul(str, 10, &viper_tpm) >= 0;
}
__setup("tpm=", viper_tpm_setup);
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] [arch/arm/mach-s3c24xx] replace strict_strto* with kstrto*
Replace obsolete strict_strto call with kstrto
Signed-off-by: Daniel Walter
---
arch/arm/mach-s3c24xx/mach-jive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-s3c24xx/mach-jive.c
b/arch/arm/mach-s3c24xx/mach-jive.c
index e81ea82..bac9bb5 100644
--- a/arch/arm/mach-s3c24xx/mach-jive.c
+++ b/arch/arm/mach-s3c24xx/mach-jive.c
@@ -243,7 +243,7 @@ static int __init jive_mtdset(char *options)
if (options == NULL || options[0] == '\0')
return 0;
- if (strict_strtoul(options, 10, &set)) {
+ if (kstrtoul(options, 10, &set)) {
printk(KERN_ERR "failed to parse mtdset=%s\n", options);
return 0;
}
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Revert "block: add __init to blkcg_policy_register"
This reverts commit a2d445d44000
Adding __init to blkcg_policy_register makes it unreliable when
loading cfq at runtime.
(Similar problem to b5097e956a4d "block: add __init to elv_register"
reported by Damien Wyart).
Cc: Jens Axboe
Cc: Damien Wyart
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
block/blk-cgroup.c | 2 +-
block/blk-cgroup.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 069bc20..9f5bce3 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -1093,7 +1093,7 @@ EXPORT_SYMBOL_GPL(blkcg_deactivate_policy);
* Register @pol with blkcg core. Might sleep and @pol may be modified on
* successful registration. Returns 0 on success and -errno on failure.
*/
-int __init blkcg_policy_register(struct blkcg_policy *pol)
+int blkcg_policy_register(struct blkcg_policy *pol)
{
int i, ret;
diff --git a/block/blk-cgroup.h b/block/blk-cgroup.h
index cbb7f94..d692b29 100644
--- a/block/blk-cgroup.h
+++ b/block/blk-cgroup.h
@@ -145,7 +145,7 @@ void blkcg_drain_queue(struct request_queue *q);
void blkcg_exit_queue(struct request_queue *q);
/* Blkio controller policy registration */
-int __init blkcg_policy_register(struct blkcg_policy *pol);
+int blkcg_policy_register(struct blkcg_policy *pol);
void blkcg_policy_unregister(struct blkcg_policy *pol);
int blkcg_activate_policy(struct request_queue *q,
const struct blkcg_policy *pol);
@@ -580,7 +580,7 @@ static inline struct blkcg_gq *blkg_lookup(struct blkcg
*blkcg, void *key) { ret
static inline int blkcg_init_queue(struct request_queue *q) { return 0; }
static inline void blkcg_drain_queue(struct request_queue *q) { }
static inline void blkcg_exit_queue(struct request_queue *q) { }
-static inline int __init blkcg_policy_register(struct blkcg_policy *pol) {
return 0; }
+static inline int blkcg_policy_register(struct blkcg_policy *pol) { return 0; }
static inline void blkcg_policy_unregister(struct blkcg_policy *pol) { }
static inline int blkcg_activate_policy(struct request_queue *q,
const struct blkcg_policy *pol) {
return 0; }
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] [arch/powerpc] replace obsolete strict_strto* calls
Replace strict_strto calls with more appropriate kstrto calls
Signed-off-by: Daniel Walter
---
arch/powerpc/kernel/setup_64.c| 6 +++---
arch/powerpc/kernel/vio.c | 2 +-
arch/powerpc/platforms/pseries/dlpar.c| 4 ++--
arch/powerpc/platforms/pseries/mobility.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index ee082d7..5257166 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -149,13 +149,13 @@ static void check_smt_enabled(void)
else if (!strcmp(smt_enabled_cmdline, "off"))
smt_enabled_at_boot = 0;
else {
- long smt;
+ int smt;
int rc;
- rc = strict_strtol(smt_enabled_cmdline, 10, &smt);
+ rc = kstrtoint(smt_enabled_cmdline, 10, &smt);
if (!rc)
smt_enabled_at_boot =
- min(threads_per_core, (int)smt);
+ min(threads_per_core, smt);
}
} else {
dn = of_find_node_by_path("/options");
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 904c661..5bfdab9 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -977,7 +977,7 @@ static ssize_t viodev_cmo_desired_set(struct device *dev,
size_t new_desired;
int ret;
- ret = strict_strtoul(buf, 10, &new_desired);
+ ret = kstrtoul(buf, 10, &new_desired);
if (ret)
return ret;
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/platforms/pseries/dlpar.c
index 022b38e..abc6892 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -399,10 +399,10 @@ out:
static ssize_t dlpar_cpu_probe(const char *buf, size_t count)
{
struct device_node *dn, *parent;
- unsigned long drc_index;
+ u32 drc_index;
int rc;
- rc = strict_strtoul(buf, 0, &drc_index);
+ rc = kstrtou32(buf, 0, &drc_index);
if (rc)
return -EINVAL;
diff --git a/arch/powerpc/platforms/pseries/mobility.c
b/arch/powerpc/platforms/pseries/mobility.c
index bde7eba..0694ac6 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -319,7 +319,7 @@ static ssize_t migrate_store(struct class *class, struct
class_attribute *attr,
u64 streamid;
int rc;
- rc = strict_strtoull(buf, 0, &streamid);
+ rc = kstrtou64(buf, 0, &streamid);
if (rc)
return rc;
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] [arch/arm/mach-w90x900] replace obsolete strict_strto
Replace obsolete strict_strto with kstrto calls Signed-off-by: Daniel Walter --- arch/arm/mach-w90x900/cpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-w90x900/cpu.c b/arch/arm/mach-w90x900/cpu.c index b1eabaa..213230ee 100644 --- a/arch/arm/mach-w90x900/cpu.c +++ b/arch/arm/mach-w90x900/cpu.c @@ -178,7 +178,8 @@ static int __init nuc900_set_cpufreq(char *str) if (!*str) return 0; - strict_strtoul(str, 0, &cpufreq); + if (kstrtoul(str, 0, &cpufreq)) + return 0; nuc900_clock_source(NULL, "ext"); -- 2.0.0.526.g5318336 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] [drivers/scsi] replace strict_strto calls
Replace obsolete strict_strto with more appropriate kstrto calls
Signed-off-by: Daniel Walter
---
drivers/scsi/pmcraid.c| 4 ++--
drivers/scsi/scsi_sysfs.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index be8ce54..3762488 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4213,9 +4213,9 @@ static ssize_t pmcraid_store_log_level(
{
struct Scsi_Host *shost;
struct pmcraid_instance *pinstance;
- unsigned long val;
+ u8 val;
- if (strict_strtoul(buf, 10, &val))
+ if (kstrtou8(buf, 10, &val))
return -EINVAL;
/* log-level should be from 0 to 2 */
if (val > 2)
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 074e8cc..80f715d 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -885,9 +885,9 @@ sdev_store_queue_ramp_up_period(struct device *dev,
const char *buf, size_t count)
{
struct scsi_device *sdev = to_scsi_device(dev);
- unsigned long period;
+ unsigned int period;
- if (strict_strtoul(buf, 10, &period))
+ if (kstrtouint(buf, 10, &period))
return -EINVAL;
sdev->queue_ramp_up_period = msecs_to_jiffies(period);
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7] iio: add support of the max1027
On 16/06/14 21:06, Jonathan Cameron wrote:
On 14/06/14 23:27, Philippe Reynes wrote:
This driver add partial support of the
maxim 1027/1029/1031. Differential mode is not
supported.
It was tested on armadeus apf27 board.
Signed-off-by: Philippe Reynes
I'm happy with this now.
Hartmut, anything else you want to raise, or do you want to add
a reviewed by? No particular rush at this point in a cycle so
would be nice to acknowledge your hard work - I am very pleased
to see how my reviewing you (and others!) are now doing on this
list. Makes my side of things much more manageable!
I'll take that as a no ;)
Applied to the togreg branch of iio.git. Will be initially pushed
out as testing to let the autobuilders work their magic.
Thanks. It's always a little bruising to go through to V7 on a patch
so thanks for keeping at it!
Jonathan
J
---
.../devicetree/bindings/iio/adc/max1027-adc.txt| 22 +
drivers/iio/adc/Kconfig|9 +
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/max1027.c | 521
4 files changed, 553 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/adc/max1027-adc.txt
create mode 100644 drivers/iio/adc/max1027.c
Changelog:
v7: (thanks Hartmut Knaack and Jonathan Cameron for the feedback)
- use const with info in max1027_state
- use bitops.h (and BIT)
- separate operators with whitespace
- define a reg member in max1027_state
v6: (thanks Peter Meerwald for the feedback)
- dont use index with temperature
- use const on scan mask
- use __be16 * for buffer
- return -EBUSY if trigger is already running
- replace it by interrupt in comment
- dont finish case with ";"
- use iio_push_to_buffers
- remove useless initialization of st->buffer
- remove useless obvious comment
v5: (thanks Jonathan Cameron for the feedback)
- add validate_trigger
- add validate_device
- remove useless (void *) cast
- use allocated buffer for spi_write
v4: (thanks Jonathan Cameron for the feedback)
- use iio_trigger_generic_data_rdy_poll
v3: (thanks Hartmut Knaack, Lars-Peter Clausen and Jonathan Cameron for the
feedback)
- move to drivers/iio/adc (was in staging)
- clean binding doc
- drop empty update_scan_mode callback
- add a lock around single channel read code
- remove useless wrappers around spi_write and spi_read
- fix available scan mask (a bit was missing)
- remove useless header
- some others little cleanp
v2: (thanks Hartmut Knaack and Jonathan Cameron for the feedback)
- really use devm_*
- use demux magic
- use spi_read and spi_write (instead of spi_sync)
- use define for register (instead of hardcoded value)
diff --git a/Documentation/devicetree/bindings/iio/adc/max1027-adc.txt
b/Documentation/devicetree/bindings/iio/adc/max1027-adc.txt
new file mode 100644
index 000..a8770cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/max1027-adc.txt
@@ -0,0 +1,22 @@
+* Maxim 1027/1029/1031 Analog to Digital Converter (ADC)
+
+Required properties:
+ - compatible: Should be "maxim,max1027" or "maxim,max1029" or "maxim,max1031"
+ - reg: SPI chip select number for the device
+ - interrupt-parent: phandle to the parent interrupt controller
+ see: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ - interrupts: IRQ line for the ADC
+ see: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+Recommended properties:
+- spi-max-frequency: Definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Example:
+adc@0 {
+compatible = "maxim,max1027";
+reg = <0>;
+interrupt-parent = <&gpio5>;
+interrupts = <15 IRQ_TYPE_EDGE_RISING>;
+spi-max-frequency = <100>;
+};
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a80d236..20a7073 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -131,6 +131,15 @@ config LP8788_ADC
help
Say yes here to build support for TI LP8788 ADC.
+config MAX1027
+tristate "Maxim max1027 ADC driver"
+depends on SPI
+select IIO_BUFFER
+select IIO_TRIGGERED_BUFFER
+help
+ Say yes here to build support for Maxim SPI ADC models
+ max1027, max1029 and max1031.
+
config MAX1363
tristate "Maxim max1363 ADC driver"
depends on I2C
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 9d60f2d..38cf5c3 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_AD799X) += ad799x.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
+obj-$(CONFIG_MAX1027) += max1027.o
obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
diff --git a/drivers/iio/adc/max1027.c b/drivers/iio/adc/max1027.c
new file mode 100644
index 000..87ee1c7
--- /dev/null
+++ b/drivers/
Re: [v3.10.y][v3.11.y][v3.12.y][v3.13.y][v3.14.y][PATCH 1/1][V2] ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined
On Fri, 2014-06-20 at 14:21 -0400, Joseph Salisbury wrote: [...] > I looked at this some more. It seems like my v2 backport may be the > most suitable for the releases mentioned in the subject line, but I'd > like to get additional feedback. > > The lines added by commit a5065eb just get removed by commit b7a77235. > Also, if I apply commit a5065eb, it will also require a backport to pull > in just a piece of code(Remove snd_printk() and add dev_dbg()) from > another prior commit(0ba41d9). No backport would be needed at all if I > cherry-pick 0ba41d9, but that commit seems to have too may changes for a > stable release. Keep the changes squashed together if you like, but do include both commit hashes and commit messages. Ben. -- Ben Hutchings Who are all these weirdos? - David Bowie, reading IRC for the first time signature.asc Description: This is a digitally signed message part
[PATCH 6/9] [arch/x86] replace strict_strto calls
Replace obsolete strict_strto calls with appropriate kstrto calls
Signed-off-by: Daniel Walter
Acked-by: Borislav Petkov
---
arch/x86/kernel/cpu/intel_cacheinfo.c | 4 ++--
arch/x86/kernel/cpu/mcheck/mce.c | 6 +++---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 4 ++--
arch/x86/kvm/mmu_audit.c | 2 +-
arch/x86/platform/uv/tlb_uv.c | 2 +-
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index a952e9c..4ff210a 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -461,7 +461,7 @@ static ssize_t store_cache_disable(struct _cpuid4_info
*this_leaf,
cpu = cpumask_first(to_cpumask(this_leaf->shared_cpu_map));
- if (strict_strtoul(buf, 10, &val) < 0)
+ if (kstrtoul(buf, 10, &val) < 0)
return -EINVAL;
err = amd_set_l3_disable_slot(this_leaf->base.nb, cpu, slot, val);
@@ -511,7 +511,7 @@ store_subcaches(struct _cpuid4_info *this_leaf, const char
*buf, size_t count,
if (!this_leaf->base.nb || !amd_nb_has_feature(AMD_NB_L3_PARTITIONING))
return -EINVAL;
- if (strict_strtoul(buf, 16, &val) < 0)
+ if (kstrtoul(buf, 16, &val) < 0)
return -EINVAL;
if (amd_set_subcaches(cpu, val))
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index bb92f38..a801a35 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -2136,7 +2136,7 @@ static ssize_t set_bank(struct device *s, struct
device_attribute *attr,
{
u64 new;
- if (strict_strtoull(buf, 0, &new) < 0)
+ if (kstrtou64(buf, 0, &new) < 0)
return -EINVAL;
attr_to_bank(attr)->ctl = new;
@@ -2174,7 +2174,7 @@ static ssize_t set_ignore_ce(struct device *s,
{
u64 new;
- if (strict_strtoull(buf, 0, &new) < 0)
+ if (kstrtou64(buf, 0, &new) < 0)
return -EINVAL;
if (mca_cfg.ignore_ce ^ !!new) {
@@ -2198,7 +2198,7 @@ static ssize_t set_cmci_disabled(struct device *s,
{
u64 new;
- if (strict_strtoull(buf, 0, &new) < 0)
+ if (kstrtou64(buf, 0, &new) < 0)
return -EINVAL;
if (mca_cfg.cmci_disabled ^ !!new) {
diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c
b/arch/x86/kernel/cpu/mcheck/mce_amd.c
index 603df4f..1e49f8f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -353,7 +353,7 @@ store_interrupt_enable(struct threshold_block *b, const
char *buf, size_t size)
if (!b->interrupt_capable)
return -EINVAL;
- if (strict_strtoul(buf, 0, &new) < 0)
+ if (kstrtoul(buf, 0, &new) < 0)
return -EINVAL;
b->interrupt_enable = !!new;
@@ -372,7 +372,7 @@ store_threshold_limit(struct threshold_block *b, const char
*buf, size_t size)
struct thresh_restart tr;
unsigned long new;
- if (strict_strtoul(buf, 0, &new) < 0)
+ if (kstrtoul(buf, 0, &new) < 0)
return -EINVAL;
if (new > THRESHOLD_MAX)
diff --git a/arch/x86/kvm/mmu_audit.c b/arch/x86/kvm/mmu_audit.c
index 1185fe7..9ade5cf 100644
--- a/arch/x86/kvm/mmu_audit.c
+++ b/arch/x86/kvm/mmu_audit.c
@@ -273,7 +273,7 @@ static int mmu_audit_set(const char *val, const struct
kernel_param *kp)
int ret;
unsigned long enable;
- ret = strict_strtoul(val, 10, &enable);
+ ret = kstrtoul(val, 10, &enable);
if (ret < 0)
return -EINVAL;
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index dfe605a..ccc3210 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -1476,7 +1476,7 @@ static ssize_t ptc_proc_write(struct file *file, const
char __user *user,
return count;
}
- if (strict_strtol(optstr, 10, &input_arg) < 0) {
+ if (kstrtol(optstr, 10, &input_arg) < 0) {
printk(KERN_DEBUG "%s is invalid\n", optstr);
return -EINVAL;
}
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] [include/linux] remove strict_strto* definitions
Remove obsolete and unused strict_strto* functions Signed-off-by: Daniel Walter Acked-by: Steven Rostedt --- include/linux/kernel.h | 4 1 file changed, 4 deletions(-) diff --git a/include/linux/kernel.h b/include/linux/kernel.h index 4c52907..a39043c 100644 --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -376,10 +376,6 @@ extern unsigned long simple_strtoul(const char *,char **,unsigned int); extern long simple_strtol(const char *,char **,unsigned int); extern unsigned long long simple_strtoull(const char *,char **,unsigned int); extern long long simple_strtoll(const char *,char **,unsigned int); -#define strict_strtoul kstrtoul -#define strict_strtol kstrtol -#define strict_strtoullkstrtoull -#define strict_strtoll kstrtoll extern int num_to_str(char *buf, int size, unsigned long long num); -- 2.0.0.526.g5318336 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/9] [net/sunrpc] replace strict_strto calls
Replace obsolete strict_strto calls with appropriate kstrto calls
Signed-off-by: Daniel Walter
---
net/sunrpc/addr.c | 16 ++--
net/sunrpc/auth.c | 2 +-
net/sunrpc/xprtsock.c | 4 ++--
3 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/net/sunrpc/addr.c b/net/sunrpc/addr.c
index a622ad6..2e0a6f9 100644
--- a/net/sunrpc/addr.c
+++ b/net/sunrpc/addr.c
@@ -176,7 +176,7 @@ static int rpc_parse_scope_id(struct net *net, const char
*buf,
len = (buf + buflen) - delim - 1;
p = kstrndup(delim + 1, len, GFP_KERNEL);
if (p) {
- unsigned long scope_id = 0;
+ u32 scope_id = 0;
struct net_device *dev;
dev = dev_get_by_name(net, p);
@@ -184,7 +184,7 @@ static int rpc_parse_scope_id(struct net *net, const char
*buf,
scope_id = dev->ifindex;
dev_put(dev);
} else {
- if (strict_strtoul(p, 10, &scope_id) == 0) {
+ if (kstrtou32(p, 10, &scope_id) == 0) {
kfree(p);
return 0;
}
@@ -304,7 +304,7 @@ char *rpc_sockaddr2uaddr(const struct sockaddr *sap, gfp_t
gfp_flags)
* @sap: buffer into which to plant socket address
* @salen: size of buffer
*
- * @uaddr does not have to be '\0'-terminated, but strict_strtoul() and
+ * @uaddr does not have to be '\0'-terminated, but kstrtou8() and
* rpc_pton() require proper string termination to be successful.
*
* Returns the size of the socket address if successful; otherwise
@@ -315,7 +315,7 @@ size_t rpc_uaddr2sockaddr(struct net *net, const char
*uaddr,
const size_t salen)
{
char *c, buf[RPCBIND_MAXUADDRLEN + sizeof('\0')];
- unsigned long portlo, porthi;
+ u8 portlo, porthi;
unsigned short port;
if (uaddr_len > RPCBIND_MAXUADDRLEN)
@@ -327,18 +327,14 @@ size_t rpc_uaddr2sockaddr(struct net *net, const char
*uaddr,
c = strrchr(buf, '.');
if (unlikely(c == NULL))
return 0;
- if (unlikely(strict_strtoul(c + 1, 10, &portlo) != 0))
- return 0;
- if (unlikely(portlo > 255))
+ if (unlikely(kstrtou8(c + 1, 10, &portlo) != 0))
return 0;
*c = '\0';
c = strrchr(buf, '.');
if (unlikely(c == NULL))
return 0;
- if (unlikely(strict_strtoul(c + 1, 10, &porthi) != 0))
- return 0;
- if (unlikely(porthi > 255))
+ if (unlikely(kstrtou8(c + 1, 10, &porthi) != 0))
return 0;
port = (unsigned short)((porthi << 8) | portlo);
diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
index 247e973..7e9e4bb 100644
--- a/net/sunrpc/auth.c
+++ b/net/sunrpc/auth.c
@@ -48,7 +48,7 @@ static int param_set_hashtbl_sz(const char *val, const struct
kernel_param *kp)
if (!val)
goto out_inval;
- ret = strict_strtoul(val, 0, &num);
+ ret = kstrtoul(val, 0, &num);
if (ret == -EINVAL)
goto out_inval;
nbits = fls(num);
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index be8bbd5..1f2baac 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -3054,12 +3054,12 @@ static int param_set_uint_minmax(const char *val,
const struct kernel_param *kp,
unsigned int min, unsigned int max)
{
- unsigned long num;
+ unsigned int num;
int ret;
if (!val)
return -EINVAL;
- ret = strict_strtoul(val, 0, &num);
+ ret = kstrtouint(val, 0, &num);
if (ret == -EINVAL || num < min || num > max)
return -EINVAL;
*((unsigned int *)kp->arg) = num;
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [for-next][PATCH] tracing: Add __field_struct macro for TRACE_EVENT()
On Sat, Jun 21, 2014 at 07:50:25AM -0400, Steven Rostedt wrote: > > Updates to the RAS tracepoints found that the __field() macro has a bug > in it where you can not use it with structures. It only works with > primitives. This is because of an added check to determine if the field > is signed or not. > > A new macro is created called __field_struct() that can be used to save > structured data directly in the tracepoint and not have to settle for > storing as an array with memcpy. > > -- Steve > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git > for-next > > Head SHA1: 4d4c9cc839a308be3289a361ccba4447ee140552 > > > Steven Rostedt (1): > tracing: Add __field_struct macro for TRACE_EVENT() > > > include/trace/ftrace.h | 33 > ++ > samples/trace_events/trace-events-sample.h | 3 ++- > 2 files changed, 35 insertions(+), 1 deletion(-) > --- > commit 4d4c9cc839a308be3289a361ccba4447ee140552 > Author: Steven Rostedt > Date: Tue Jun 17 08:59:16 2014 -0400 > > tracing: Add __field_struct macro for TRACE_EVENT() > > Currently the __field() macro in TRACE_EVENT is only good for primitive > values, such as integers and pointers, but it fails on complex data types > such as structures or unions. This is because the __field() macro > determines if the variable is signed or not with the test of: > > (((type)(-1)) < (type)1) > > Unfortunately, that fails when type is a structure. > > Since trace events should support structures as fields a new macro > is created for such a case called __field_struct() which acts exactly > the same as __field() does but it does not do the signed type check > and just uses a constant false for that answer. > > Cc: Tony Luck > Signed-off-by: Steven Rostedt Acked-by: Borislav Petkov -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/trace/syscall.h: Use HAVE_SYSCALL_TRACEPOINTS instead of TRACEPOINTS
On 06/21/2014 11:43 AM, Steven Rostedt wrote:
> On Sat, 21 Jun 2014 10:32:37 +0800
> Chen Gang wrote:
>
>> diff --git a/include/trace/syscall.h b/include/trace/syscall.h
>> index 291c282..a709cbd 100644
>> --- a/include/trace/syscall.h
>> +++ b/include/trace/syscall.h
>> @@ -33,7 +33,7 @@ struct syscall_metadata {
>> struct ftrace_event_call *exit_event;
>> };
>>
>> -#ifdef CONFIG_TRACEPOINTS
>> +#ifdef CONFIG_HAVE_SYSCALL_TRACEPOINTS
>> static inline void syscall_tracepoint_update(struct task_struct *p)
>> {
>> if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
>
> This has already been fixed and is in my for-next branch getting ready
> to be pushed.
>
OK, thank you for replying in time.
Thanks.
--
Open share and attitude like air warter and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Potential NULL pointer deference in drbg_ctr_df
The handling of additional input data / personalization string data may
be subject to a NULL pointer deference for the CTR DRBG. The
caller-provided data may be NULL which must be caught by the DRBG.
Reported-by: kbuild test robot
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index faaa2ce..8e7c302 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -513,17 +513,20 @@ static int drbg_ctr_df(struct drbg_state *drbg,
drbg_string_fill(&S2, L_N, sizeof(L_N));
drbg_string_fill(&S4, pad, padlen);
S1.next = &S2;
- S2.next = addtl;
- /*
-* splice in addtl between S2 and S4 -- we place S4 at the end of the
-* input data chain
-*/
- tempstr = addtl;
- for (; NULL != tempstr; tempstr = tempstr->next)
- if (NULL == tempstr->next)
- break;
- tempstr->next = &S4;
+ if (NULL == addtl) {
+ S2.next = &S4;
+ } else {
+ /*
+* splice in addtl between S2 and S4 -- we place S4 at the end
+* of the input data chain
+*/
+ S2.next = addtl;
+ tempstr = addtl;
+ while (tempstr->next)
+ tempstr = tempstr->next;
+ tempstr->next = &S4;
+ }
/* 10.4.2 step 9 */
while (templen < (drbg_keylen(drbg) + (drbg_blocklen(drbg {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cxgb4: use dev_port to identify ports
Commit 3f85944fe207d0225ef21a2c0951d4946fc9a95d ("net: Add sysfs file
for port number") introduce dev_port to network devices. cxgb4 adapters
have multiple ports on the same PCI function, and used dev_id to
identify those ports. That use was removed by commit
8c367fcbe6549195d2eb11e62bea233f811aad41 ("cxgb4: Do not set
net_device::dev_id to VI index"), since dev_id should be used only when
devices share the same MAC address.
Using dev_port for cxgb4 allows different ports on the same PCI function
to be identified.
Signed-off-by: Thadeu Lima de Souza Cascardo
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index bba6768..931478e 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -3962,6 +3962,7 @@ int t4_port_init(struct adapter *adap, int mbox, int pf,
int vf)
p->lport = j;
p->rss_size = rss_size;
memcpy(adap->port[i]->dev_addr, addr, ETH_ALEN);
+ adap->port[i]->dev_port = j;
ret = ntohl(c.u.info.lstatus_to_modtype);
p->mdio_addr = (ret & FW_PORT_CMD_MDIOCAP) ?
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] staging: rtl8188eu: Consolidate usb operation code.
navin patidar (7): staging: rtl8188eu: Merge hal/usb_ops_linux.c into os_dep/usb_ops_linux.c staging: rtl8188eu: Remove macros specific to kernel version < 2.6.12 staging:rtl8188eu:usb_ops.h:Remove unused enum, macros and function declaration staging: rtl8188eu: usb_ops.h: Remove macro rtw_usb_control_msg() staging: rtl8188eu: Remove inline function rtw_inc_and_chk_continual_urb_error() staging: rtl8188eu: Remove continual_urb_error from struct dvobj_priv staging: rtl8188eu: Merge usb_ops.h into usb_ops_linux.h drivers/staging/rtl8188eu/Makefile|1 - drivers/staging/rtl8188eu/core/rtw_ioctl_set.c|1 - drivers/staging/rtl8188eu/core/rtw_recv.c |1 - drivers/staging/rtl8188eu/core/rtw_xmit.c |1 - drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c |2 - drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c|2 +- drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c|2 +- drivers/staging/rtl8188eu/hal/usb_halinit.c |1 - drivers/staging/rtl8188eu/hal/usb_ops_linux.c | 665 - drivers/staging/rtl8188eu/include/drv_types.h |2 - drivers/staging/rtl8188eu/include/usb_ops.h | 112 drivers/staging/rtl8188eu/include/usb_ops_linux.h | 25 + drivers/staging/rtl8188eu/os_dep/ioctl_linux.c|1 - drivers/staging/rtl8188eu/os_dep/recv_linux.c |2 +- drivers/staging/rtl8188eu/os_dep/usb_intf.c |4 +- drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 630 ++- 16 files changed, 658 insertions(+), 794 deletions(-) delete mode 100644 drivers/staging/rtl8188eu/hal/usb_ops_linux.c delete mode 100644 drivers/staging/rtl8188eu/include/usb_ops.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] staging: rtl8188eu: Remove continual_urb_error from struct dvobj_priv
rtw_inc_and_chk_continual_urb_error() was only user of continual_urb_error,
which has been removed.
Signed-off-by: navin patidar
---
drivers/staging/rtl8188eu/include/drv_types.h|2 --
drivers/staging/rtl8188eu/include/usb_ops.h |8
drivers/staging/rtl8188eu/os_dep/usb_intf.c |2 --
drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c |3 ---
4 files changed, 15 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/drv_types.h
b/drivers/staging/rtl8188eu/include/drv_types.h
index 6750135..097fcc9 100644
--- a/drivers/staging/rtl8188eu/include/drv_types.h
+++ b/drivers/staging/rtl8188eu/include/drv_types.h
@@ -174,8 +174,6 @@ struct dvobj_priv {
struct usb_interface *pusbintf;
struct usb_device *pusbdev;
-
- atomic_t continual_urb_error;
};
static inline struct device *dvobj_to_dev(struct dvobj_priv *dvobj)
diff --git a/drivers/staging/rtl8188eu/include/usb_ops.h
b/drivers/staging/rtl8188eu/include/usb_ops.h
index eb934bf..ea23b459 100644
--- a/drivers/staging/rtl8188eu/include/usb_ops.h
+++ b/drivers/staging/rtl8188eu/include/usb_ops.h
@@ -34,14 +34,6 @@
#include
-/*
-* Set the continual_urb_error of this @param dvobjprive to 0
-*/
-static inline void rtw_reset_continual_urb_error(struct dvobj_priv *dvobj)
-{
- atomic_set(&dvobj->continual_urb_error, 0);
-}
-
#define USB_HIGH_SPEED_BULK_SIZE 512
#define USB_FULL_SPEED_BULK_SIZE 64
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index c4a4880..4af2c95 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -121,8 +121,6 @@ static struct dvobj_priv *usb_dvobj_init(struct
usb_interface *usb_intf)
if (!pdvobjpriv->usb_vendor_req_buf)
goto free_dvobj;
- rtw_reset_continual_urb_error(pdvobjpriv);
-
usb_get_dev(pusbd);
status = _SUCCESS;
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
index 9f9bb06..ad7c48e 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
@@ -276,7 +276,6 @@ static int usbctrl_vendorreq(struct adapter *adapt, u8
request, u16 value, u16 i
status = usb_control_msg(udev, pipe, request, reqtype, value,
index, pIo_buf, len, RTW_USB_CONTROL_MSG_TIMEOUT);
if (status == len) { /* Success this control transfer. */
- rtw_reset_continual_urb_error(dvobjpriv);
if (requesttype == 0x01)
memcpy(pdata, pIo_buf, len);
} else { /* error cases */
@@ -408,8 +407,6 @@ static void usb_read_port_complete(struct urb *purb, struct
pt_regs *regs)
usb_read_port(adapt, precvpriv->ff_hwaddr, 0, (unsigned
char *)precvbuf);
DBG_88E("%s()-%d: RX Warning!\n", __func__, __LINE__);
} else {
- rtw_reset_continual_urb_error(adapter_to_dvobj(adapt));
-
skb_put(precvbuf->pskb, purb->actual_length);
skb_queue_tail(&precvpriv->rx_skb_queue,
precvbuf->pskb);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] staging: rtl8188eu: Remove inline function rtw_inc_and_chk_continual_urb_error()
rtw_inc_and_chk_continual_urb_error() is used to check if device is
removed unexpectedly, to do that we can just check status of urb in
usb_read_port_complete() and usbctrl_vendorreq() doed that by checking
return value of usb_control_msg().
Signed-off-by: navin patidar
---
drivers/staging/rtl8188eu/include/usb_ops.h | 19 ---
drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 10 +-
2 files changed, 1 insertion(+), 28 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/usb_ops.h
b/drivers/staging/rtl8188eu/include/usb_ops.h
index 79d206e..eb934bf 100644
--- a/drivers/staging/rtl8188eu/include/usb_ops.h
+++ b/drivers/staging/rtl8188eu/include/usb_ops.h
@@ -35,25 +35,6 @@
#include
/*
- * Increase and check if the continual_urb_error of this @param dvobjprivei
- * is larger than MAX_CONTINUAL_URB_ERR
- * @return true:
- * @return false:
- */
-static inline int rtw_inc_and_chk_continual_urb_error(struct dvobj_priv *dvobj)
-{
- int ret = false;
- int value;
- value = atomic_inc_return(&dvobj->continual_urb_error);
- if (value > MAX_CONTINUAL_URB_ERR) {
- DBG_88E("[dvobj:%p][ERROR] continual_urb_error:%d > %d\n",
- dvobj, value, MAX_CONTINUAL_URB_ERR);
- ret = true;
- }
- return ret;
-}
-
-/*
* Set the continual_urb_error of this @param dvobjprive to 0
*/
static inline void rtw_reset_continual_urb_error(struct dvobj_priv *dvobj)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
index 363f7f5..9f9bb06 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
@@ -300,11 +300,6 @@ static int usbctrl_vendorreq(struct adapter *adapt, u8
request, u16 value, u16 i
}
}
- if (rtw_inc_and_chk_continual_urb_error(dvobjpriv)) {
- adapt->bSurpriseRemoved = true;
- break;
- }
-
}
/* firmware download is checksumed, don't retry */
@@ -432,15 +427,12 @@ static void usb_read_port_complete(struct urb *purb,
struct pt_regs *regs)
skb_put(precvbuf->pskb, purb->actual_length);
precvbuf->pskb = NULL;
- if
(rtw_inc_and_chk_continual_urb_error(adapter_to_dvobj(adapt)))
- adapt->bSurpriseRemoved = true;
-
switch (purb->status) {
case -EINVAL:
case -EPIPE:
case -ENODEV:
case -ESHUTDOWN:
- RT_TRACE(_module_hci_ops_os_c_, _drv_err_,
("usb_read_port_complete:bSurpriseRemoved=true\n"));
+ adapt->bSurpriseRemoved = true;
case -ENOENT:
adapt->bDriverStopped = true;
RT_TRACE(_module_hci_ops_os_c_, _drv_err_,
("usb_read_port_complete:bDriverStopped=true\n"));
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] staging: rtl8188eu: usb_ops.h: Remove macro rtw_usb_control_msg()
Signed-off-by: navin patidar
---
drivers/staging/rtl8188eu/include/usb_ops.h |5 -
drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c |2 +-
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/usb_ops.h
b/drivers/staging/rtl8188eu/include/usb_ops.h
index 74009ca..79d206e 100644
--- a/drivers/staging/rtl8188eu/include/usb_ops.h
+++ b/drivers/staging/rtl8188eu/include/usb_ops.h
@@ -32,11 +32,6 @@
#define MAX_VENDOR_REQ_CMD_SIZE254 /* 8188cu SIE Support */
#define MAX_USB_IO_CTL_SIZE(MAX_VENDOR_REQ_CMD_SIZE + ALIGNMENT_UNIT)
-#define rtw_usb_control_msg(dev, pipe, request, requesttype, \
- value, index, data, size, timeout_ms) \
- usb_control_msg((dev), (pipe), (request), (requesttype), (value),\
- (index), (data), (size), (timeout_ms))
-
#include
/*
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
index 7563188..363f7f5 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
@@ -273,7 +273,7 @@ static int usbctrl_vendorreq(struct adapter *adapt, u8
request, u16 value, u16 i
memcpy(pIo_buf, pdata, len);
}
- status = rtw_usb_control_msg(udev, pipe, request, reqtype,
value, index, pIo_buf, len, RTW_USB_CONTROL_MSG_TIMEOUT);
+ status = usb_control_msg(udev, pipe, request, reqtype, value,
index, pIo_buf, len, RTW_USB_CONTROL_MSG_TIMEOUT);
if (status == len) { /* Success this control transfer. */
rtw_reset_continual_urb_error(dvobjpriv);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] staging:rtl8188eu:usb_ops.h:Remove unused enum, macros and function declaration
Signed-off-by: navin patidar
---
drivers/staging/rtl8188eu/include/usb_ops.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/usb_ops.h
b/drivers/staging/rtl8188eu/include/usb_ops.h
index e10b711..74009ca 100644
--- a/drivers/staging/rtl8188eu/include/usb_ops.h
+++ b/drivers/staging/rtl8188eu/include/usb_ops.h
@@ -27,13 +27,7 @@
#define REALTEK_USB_VENQT_READ 0xC0
#define REALTEK_USB_VENQT_WRITE0x40
-#define REALTEK_USB_VENQT_CMD_REQ 0x05
-#define REALTEK_USB_VENQT_CMD_IDX 0x00
-enum{
- VENDOR_WRITE = 0x00,
- VENDOR_READ = 0x01,
-};
#define ALIGNMENT_UNIT 16
#define MAX_VENDOR_REQ_CMD_SIZE254 /* 8188cu SIE Support */
#define MAX_USB_IO_CTL_SIZE(MAX_VENDOR_REQ_CMD_SIZE + ALIGNMENT_UNIT)
@@ -42,14 +36,9 @@ enum{
value, index, data, size, timeout_ms) \
usb_control_msg((dev), (pipe), (request), (requesttype), (value),\
(index), (data), (size), (timeout_ms))
-#define rtw_usb_bulk_msg(usb_dev, pipe, data, len, actual_length, timeout_ms) \
- usb_bulk_msg((usb_dev), (pipe), (data), (len), \
-(actual_length), (timeout_ms))
#include
-void rtl8188eu_set_hw_type(struct adapter *padapter);
-
/*
* Increase and check if the continual_urb_error of this @param dvobjprivei
* is larger than MAX_CONTINUAL_URB_ERR
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] staging: rtl8188eu: Merge hal/usb_ops_linux.c into os_dep/usb_ops_linux.c
Consolidate all usb operation related functions in one file.
Signed-off-by: navin patidar
---
drivers/staging/rtl8188eu/Makefile |1 -
drivers/staging/rtl8188eu/hal/usb_ops_linux.c| 665 --
drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 642 -
3 files changed, 641 insertions(+), 667 deletions(-)
delete mode 100644 drivers/staging/rtl8188eu/hal/usb_ops_linux.c
diff --git a/drivers/staging/rtl8188eu/Makefile
b/drivers/staging/rtl8188eu/Makefile
index 74a032c..2745076 100644
--- a/drivers/staging/rtl8188eu/Makefile
+++ b/drivers/staging/rtl8188eu/Makefile
@@ -46,7 +46,6 @@ r8188eu-y := \
hal/rtl8188eu_recv.o\
hal/rtl8188eu_xmit.o\
hal/usb_halinit.o \
- hal/usb_ops_linux.o \
os_dep/ioctl_linux.o\
os_dep/mlme_linux.o \
os_dep/os_intfs.o \
diff --git a/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
b/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
deleted file mode 100644
index 1002ff0..000
--- a/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
+++ /dev/null
@@ -1,665 +0,0 @@
-/**
- *
- * Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of version 2 of the GNU General Public License as
- * published by the Free Software Foundation.
- *
- * This program 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.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
- *
-
**/
-#define _HCI_OPS_OS_C_
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-static int usbctrl_vendorreq(struct adapter *adapt, u8 request, u16 value, u16
index, void *pdata, u16 len, u8 requesttype)
-{
- struct dvobj_priv *dvobjpriv = adapter_to_dvobj(adapt);
- struct usb_device *udev = dvobjpriv->pusbdev;
- unsigned int pipe;
- int status = 0;
- u8 reqtype;
- u8 *pIo_buf;
- int vendorreq_times = 0;
-
- if ((adapt->bSurpriseRemoved) || (adapt->pwrctrlpriv.pnp_bstop_trx)) {
- RT_TRACE(_module_hci_ops_os_c_, _drv_err_,
("usbctrl_vendorreq:(adapt->bSurpriseRemoved
||adapter->pwrctrlpriv.pnp_bstop_trx)!!!\n"));
- status = -EPERM;
- goto exit;
- }
-
- if (len > MAX_VENDOR_REQ_CMD_SIZE) {
- DBG_88E("[%s] Buffer len error ,vendor request failed\n",
__func__);
- status = -EINVAL;
- goto exit;
- }
-
- _enter_critical_mutex(&dvobjpriv->usb_vendor_req_mutex, NULL);
-
- /* Acquire IO memory for vendorreq */
- pIo_buf = dvobjpriv->usb_vendor_req_buf;
-
- if (pIo_buf == NULL) {
- DBG_88E("[%s] pIo_buf == NULL\n", __func__);
- status = -ENOMEM;
- goto release_mutex;
- }
-
- while (++vendorreq_times <= MAX_USBCTRL_VENDORREQ_TIMES) {
- _rtw_memset(pIo_buf, 0, len);
-
- if (requesttype == 0x01) {
- pipe = usb_rcvctrlpipe(udev, 0);/* read_in */
- reqtype = REALTEK_USB_VENQT_READ;
- } else {
- pipe = usb_sndctrlpipe(udev, 0);/* write_out */
- reqtype = REALTEK_USB_VENQT_WRITE;
- memcpy(pIo_buf, pdata, len);
- }
-
- status = rtw_usb_control_msg(udev, pipe, request, reqtype,
value, index, pIo_buf, len, RTW_USB_CONTROL_MSG_TIMEOUT);
-
- if (status == len) { /* Success this control transfer. */
- rtw_reset_continual_urb_error(dvobjpriv);
- if (requesttype == 0x01)
- memcpy(pdata, pIo_buf, len);
- } else { /* error cases */
- DBG_88E("reg 0x%x, usb %s %u fail, status:%d
value=0x%x, vendorreq_times:%d\n",
- value, (requesttype == 0x01) ? "read" : "write",
- len, status, *(u32 *)pdata, vendorreq_times);
-
- if (status < 0) {
- if (status == (-ESHUTDOWN) || status ==
-ENODEV) {
- adapt->bSurpriseRemoved = true;
- } else {
- struct hal_data_8188e *haldata =
GET_HAL_
[PATCH 2/7] staging: rtl8188eu: Remove macros specific to kernel version < 2.6.12
Signed-off-by: navin patidar
---
drivers/staging/rtl8188eu/include/usb_ops.h | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/usb_ops.h
b/drivers/staging/rtl8188eu/include/usb_ops.h
index ff730f4..e10b711 100644
--- a/drivers/staging/rtl8188eu/include/usb_ops.h
+++ b/drivers/staging/rtl8188eu/include/usb_ops.h
@@ -38,7 +38,6 @@ enum{
#define MAX_VENDOR_REQ_CMD_SIZE254 /* 8188cu SIE Support */
#define MAX_USB_IO_CTL_SIZE(MAX_VENDOR_REQ_CMD_SIZE + ALIGNMENT_UNIT)
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 12))
#define rtw_usb_control_msg(dev, pipe, request, requesttype, \
value, index, data, size, timeout_ms) \
usb_control_msg((dev), (pipe), (request), (requesttype), (value),\
@@ -46,20 +45,7 @@ enum{
#define rtw_usb_bulk_msg(usb_dev, pipe, data, len, actual_length, timeout_ms) \
usb_bulk_msg((usb_dev), (pipe), (data), (len), \
(actual_length), (timeout_ms))
-#else
-#define rtw_usb_control_msg(dev, pipe, request, requesttype, \
- value, index, data, size, timeout_ms) \
- usb_control_msg((dev), (pipe), (request), (requesttype),\
- (value), (index), (data), (size), \
- ((timeout_ms) == 0) || \
- ((timeout_ms)*HZ/1000 > 0) ?\
- ((timeout_ms)*HZ/1000) : 1)
-#define rtw_usb_bulk_msg(usb_dev, pipe, data, len, \
-actual_length, timeout_ms) \
- usb_bulk_msg((usb_dev), (pipe), (data), (len), (actual_length), \
-((timeout_ms) == 0) || ((timeout_ms)*HZ/1000 > 0) ?\
-((timeout_ms)*HZ/1000) : 1)
-#endif
+
#include
void rtl8188eu_set_hw_type(struct adapter *padapter);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] staging: rtl8188eu: Merge usb_ops.h into usb_ops_linux.h
Signed-off-by: navin patidar
---
drivers/staging/rtl8188eu/core/rtw_ioctl_set.c|1 -
drivers/staging/rtl8188eu/core/rtw_recv.c |1 -
drivers/staging/rtl8188eu/core/rtw_xmit.c |1 -
drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c |2 -
drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c|2 +-
drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c|2 +-
drivers/staging/rtl8188eu/hal/usb_halinit.c |1 -
drivers/staging/rtl8188eu/include/usb_ops.h | 55 -
drivers/staging/rtl8188eu/include/usb_ops_linux.h | 25 ++
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c|1 -
drivers/staging/rtl8188eu/os_dep/recv_linux.c |2 +-
drivers/staging/rtl8188eu/os_dep/usb_intf.c |2 +-
drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c |1 -
13 files changed, 29 insertions(+), 67 deletions(-)
delete mode 100644 drivers/staging/rtl8188eu/include/usb_ops.h
diff --git a/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
b/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
index f1398ab..3dea17f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ioctl_set.c
@@ -26,7 +26,6 @@
#include
#include
-#include
extern void indicate_wx_scan_complete_event(struct adapter *padapter);
diff --git a/drivers/staging/rtl8188eu/core/rtw_recv.c
b/drivers/staging/rtl8188eu/core/rtw_recv.c
index 0e73df5..eaf43f2 100644
--- a/drivers/staging/rtl8188eu/core/rtw_recv.c
+++ b/drivers/staging/rtl8188eu/core/rtw_recv.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index a113f0f..eb938a5 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
index 7ea0320..4d3ea7c 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
@@ -28,8 +28,6 @@
#include
-#include
-
void iol_mode_enable(struct adapter *padapter, u8 enable)
{
u8 reg_0xf0 = 0;
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
index 0f6222d..32e59c5 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
@@ -23,7 +23,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
index 4bc2ce0..3112e6c 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c
@@ -22,7 +22,7 @@
#include
#include
#include
-#include
+#include
#include
s32rtl8188eu_init_xmit_priv(struct adapter *adapt)
diff --git a/drivers/staging/rtl8188eu/hal/usb_halinit.c
b/drivers/staging/rtl8188eu/hal/usb_halinit.c
index 03701ca..8c26d0a 100644
--- a/drivers/staging/rtl8188eu/hal/usb_halinit.c
+++ b/drivers/staging/rtl8188eu/hal/usb_halinit.c
@@ -26,7 +26,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/drivers/staging/rtl8188eu/include/usb_ops.h
b/drivers/staging/rtl8188eu/include/usb_ops.h
deleted file mode 100644
index ea23b459..000
--- a/drivers/staging/rtl8188eu/include/usb_ops.h
+++ /dev/null
@@ -1,55 +0,0 @@
-/**
- *
- * Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of version 2 of the GNU General Public License as
- * published by the Free Software Foundation.
- *
- * This program 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.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
- *
- *
-
**/
-#ifndef __USB_OPS_H_
-#define __USB_OPS_H_
-
-#include
-#include
-#include
-#include
-
-#define REALTEK_USB_VENQT_READ 0xC0
-#define REALTEK_USB_VENQT_WRITE0x40
-
-#define ALIGNMENT_UNIT 16
-#define MAX_VENDOR_REQ_CMD_SIZE254 /* 8188cu SIE Support */
-#define MAX_USB_IO_CTL_SIZE(MAX_VENDOR_REQ_CMD_SIZE + ALIGNMENT_UNIT)
-
-#include
-
-#define USB_HIGH_SPEED_BULK_SIZE 512
-#define USB_
Re: [PATCH] staging:rtl8821ae: rewrite legacy wifi check in halbcoutsrc
On 06/20/2014 09:52 PM, Nick Krause wrote: Is this patch being merged or is this not an issue. I am confused did I make a mistake in my patch or is there being a different patch being merged. Thank Nick On Fri, Jun 20, 2014 at 10:34 PM, Joe Perches wrote: On Fri, 2014-06-20 at 22:26 -0400, Nick Krause wrote: Thanks for the feedback I will resend the patch fixed. Please do not. Otherwise please use Larry's idea. It's not Larry's idea. Larry is the primary contributor for Realtek drivers in staging. I have just returned from back-to-back trips and a recovery from the failure of my primary laptop. Once I get a little time, I will research this issue and let you know. In the meantime, this patch should not be merged as it is not likely correct. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtc/hctosys.c Problem during kernel boot
Am 12.06.2014 01:53, schrieb John Stultz: You can read some of the previous discussion here: https://lkml.org/lkml/2013/6/17/533 I'd be very interested in patches to resolve this! And the silence as response to my repost of my already working patches just proved that isn't true. So (John Whitmore), I suggest to not post patches, Linux kernel maintainers don't really have an interest in getting things done or to fix bugs, they just need fresh meat they can review in order to have job security and prove their status. I really wonder what's their expectation. Do they really think other people have to incorporate their (often silly) requests, making the maintainers themself not responsible for their requested changes? Do they think other people have fun and time to write and post patches again and again just to make some arbitrary maintainer happy? If there really would be an interest, a reasonable approach would be to just take my patches and put a patch on top with whatever changes someone thinks are needed. As I don't think there are changes needed, I will not add such changes using my name as author. And don't try to tell me I'm uncooperative. I've spend time to write these patches and even have written documentation I don't need myself. The uncooperative people which are blocking almost everthing and which do ignore bugs have become these people which are calling themself Linux kernel maintainers which do expect other people have to play remote keyboard and have to take responsibility for changes maintainers don't want to be responsible for themself. So the above quoted sentence is just another "marketing" verbiage, at least in my point of view. Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] video: fbdev: skeletonfb.c: Adding code to managing allocation error
Adding missing code for managing a memory allocation error that may occur.
This was partly found using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/video/fbdev/skeletonfb.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/skeletonfb.c b/drivers/video/fbdev/skeletonfb.c
index fefde7c..ee6dc7e 100644
--- a/drivers/video/fbdev/skeletonfb.c
+++ b/drivers/video/fbdev/skeletonfb.c
@@ -692,6 +692,7 @@ static int xxxfb_probe(struct pci_dev *dev, const struct
pci_device_id *ent)
if (!info) {
/* goto error path */
+ return -ENOMEM;
}
par = info->par;
@@ -746,6 +747,7 @@ static int xxxfb_probe(struct pci_dev *dev, const struct
pci_device_id *ent)
info->pixmap.addr = kmalloc(PIXMAP_SIZE, GFP_KERNEL);
if (!info->pixmap.addr) {
/* goto error */
+ return -ENOMEM;
}
info->pixmap.size = PIXMAP_SIZE;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: rtc/hctosys.c Problem during kernel boot
I'm testing them and they're working fine so far. Will handle them the next week. -- Best regards, Alessandro Zummo Tower Technologies Sent from my iPhone, please excuse my brevity. > On 21/giu/2014, at 15:08, Alexander Holler wrote: > > Am 12.06.2014 01:53, schrieb John Stultz: > >> You can read some of the previous discussion here: >> https://lkml.org/lkml/2013/6/17/533 >> >> I'd be very interested in patches to resolve this! > > And the silence as response to my repost of my already working patches just > proved that isn't true. > > So (John Whitmore), I suggest to not post patches, Linux kernel maintainers > don't really have an interest in getting things done or to fix bugs, they > just need fresh meat they can review in order to have job security and prove > their status. > > I really wonder what's their expectation. Do they really think other people > have to incorporate their (often silly) requests, making the maintainers > themself not responsible for their requested changes? Do they think other > people have fun and time to write and post patches again and again just to > make some arbitrary maintainer happy? > > If there really would be an interest, a reasonable approach would be to just > take my patches and put a patch on top with whatever changes someone thinks > are needed. As I don't think there are changes needed, I will not add such > changes using my name as author. > > And don't try to tell me I'm uncooperative. I've spend time to write these > patches and even have written documentation I don't need myself. The > uncooperative people which are blocking almost everthing and which do ignore > bugs have become these people which are calling themself Linux kernel > maintainers which do expect other people have to play remote keyboard and > have to take responsibility for changes maintainers don't want to be > responsible for themself. > > So the above quoted sentence is just another "marketing" verbiage, at least > in my point of view. > > Alexander Holler > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [memcontrol] WARNING: CPU: 0 PID: 1 at kernel/res_counter.c:28 res_counter_uncharge_locked()
On 06/20/2014 11:42 PM, Johannes Weiner wrote: > On Fri, Jun 20, 2014 at 06:27:04PM +0800, Fengguang Wu wrote: >> Greetings, >> >> 0day kernel testing robot got the below dmesg and the first bad commit is >> >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > > Thanks for the bisect. > >> commit ddc5bfec501f4be3f9e89084c2db270c0c45d1d6 >> Author: Johannes Weiner >> AuthorDate: Fri Jun 20 10:27:58 2014 +1000 >> Commit: Stephen Rothwell >> CommitDate: Fri Jun 20 10:27:58 2014 +1000 >> >> mm: memcontrol: rewrite uncharge API >> >> The memcg uncharging code that is involved towards the end of a page's >> lifetime - truncation, reclaim, swapout, migration - is impressively >> complicated and fragile. >> >> Because anonymous and file pages were always charged before they had >> their >> page->mapping established, uncharges had to happen when the page type >> could still be known from the context; as in unmap for anonymous, page >> cache removal for file and shmem pages, and swap cache truncation for >> swap >> pages. However, these operations happen well before the page is actually >> freed, and so a lot of synchronization is necessary: >> >> - Charging, uncharging, page migration, and charge migration all need >> to take a per-page bit spinlock as they could race with uncharging. >> >> - Swap cache truncation happens during both swap-in and swap-out, and >> possibly repeatedly before the page is actually freed. This means >> that the memcg swapout code is called from many contexts that make >> no sense and it has to figure out the direction from page state to >> make sure memory and memory+swap are always correctly charged. >> >> - On page migration, the old page might be unmapped but then reused, >> so memcg code has to prevent untimely uncharging in that case. >> Because this code - which should be a simple charge transfer - is so >> special-cased, it is not reusable for replace_page_cache(). >> >> But now that charged pages always have a page->mapping, introduce >> mem_cgroup_uncharge(), which is called after the final put_page(), when >> we >> know for sure that nobody is looking at the page anymore. >> >> For page migration, introduce mem_cgroup_migrate(), which is called after >> the migration is successful and the new page is fully rmapped. Because >> the old page is no longer uncharged after migration, prevent double >> charges by decoupling the page's memcg association (PCG_USED and >> pc->mem_cgroup) from the page holding an actual charge. The new bits >> PCG_MEM and PCG_MEMSW represent the respective charges and are >> transferred >> to the new page during migration. >> >> mem_cgroup_migrate() is suitable for replace_page_cache() as well, which >> gets rid of mem_cgroup_replace_page_cache(). >> >> Swap accounting is massively simplified: because the page is no longer >> uncharged as early as swap cache deletion, a new mem_cgroup_swapout() can >> transfer the page's memory+swap charge (PCG_MEMSW) to the swap entry >> before the final put_page() in page reclaim. >> >> Finally, page_cgroup changes are now protected by whatever protection the >> page itself offers: anonymous pages are charged under the page table >> lock, >> whereas page cache insertions, swapin, and migration hold the page lock. >> Uncharging happens under full exclusion with no outstanding references. >> Charging and uncharging also ensure that the page is off-LRU, which >> serializes against charge migration. Remove the very costly page_cgroup >> lock and set pc->flags non-atomically. >> >> Signed-off-by: Johannes Weiner >> Cc: Michal Hocko >> Cc: Hugh Dickins >> Cc: Tejun Heo >> Cc: Vladimir Davydov >> Signed-off-by: Andrew Morton >> >> +---+++---+ >> | | >> 5b647620c6 | ddc5bfec50 | next-20140620 | >> +---+++---+ >> | boot_successes| 60 >> | 0 | 0 | >> | boot_failures | 0 >> | 20 | 13| >> | WARNING:CPU:PID:at_kernel/res_counter.c:res_counter_uncharge_locked() | 0 >> | 20 | 13| >> | backtrace:vm_munmap | 0 >> | 20 | 13| >> | backtrace:SyS_munmap | 0 >> | 20 | 13| >> | backtrace:do_sys_op
More 3.16 vdso fallout
We've had a report[1] of d-bus getting a SEGV only on i686 machines with the 3.16 kernel. It's a bit light on specifics, but the relevant detail seems to be: "I'm pretty sure kernel is to blame here. The crash occurs when signal handler for RT signal 33 (used internaly by NPTL/pthreads) returns to address zero (not sure why). This only happens with 3.16 kernel, works fine with 3.15." and "Seems to be related to v3.16's arch/x86 VDSO changes. Works fine when booting with vdso=0." There isn't an actual backtrace for the SEGV in the bug, but we can ask for one. The kernels in question should be very recent, but lack the 5 patch series Andy recently sent as those aren't in Linus' tree yet. Not sure if those would impact anything or not. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1110968 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] PM / Runtime: let rpm_resume fail if rpm disabled and device suspended.
On Fri, 20 Jun 2014, Kevin Hilman wrote: > > For a general device, the fact that dev->power.is_suspended is set > > means the device _has_ been powered down. Even though the > > runtime_status may not have changed, the PM core has to assume the > > device is not available for use. > > This is where things get fuzzy because of the overlap between system PM > and runtime PM. It makes sense that from a system PM perspecitve, the > core has to assume the device isn't available. But from a runtime PM > perspective, we know that it is, so we allow the *runtime PM* requests > to succeed. Well, to be fair, from a runtime PM perspective the core _doesn't_ know that the device is available. For example, if we were talking about a USB device rather than an I2C device, it _wouldn't_ be available. The fact is, after ->suspend returns some devices are still available and some aren't. Currently the PM core doesn't know which are which. > > While your I2C devices may be useable even after the ->suspend callback > > returns, for most devices this isn't true. So we shouldn't allow > > rpm_resume() to return imediately when is_suspended is set. > > It's not just my I2C devices, those are just a convenient example. It's > true for any device that does a pm_runtime_get*() during its system > suspend/resume path. Yes. But what if a pm_runtime_get*() happens duing system suspend but not on the suspend path? For example, what if a workqueue routine happens to run at that time and completely independently calls pm_runtime_get_sync()? The PM core needs to know whether that call should be allowed to succeed. > > That's the intention. When is_suspended is set, the PM core assumes > > that the device has been powered down in preparation for system > > suspend. We don't want to mess that up by performing a runtime resume. > > This is where I disagree. Some devices really need to be runtime > resumed during the suspend/resume process. Okay, I believe you. But do they need to be runtime resumed by a call to pm_runtime_get_*, or could pm_runtime_force_resume() be used instead? > > Yes. But the core also has to assume that the ->runtime_resume > > callback will undo the effect of ->suspend. Therefore the core should > > not call ->runtime_resume if is_suspended is set. > > I agree with Rafael that it should be up to the bus/subsystem to > allow/deny that. How? Wouldn't that mean changing every subsystem that wants to prevent the callbacks? > > At what stage do these devices get powered down? During suspend_late > > or suspend_irq? > > Correct. > > > At such times the PM core won't invoke the runtime PM callbacks > > anyway. > > The core wont, but the bus/subsystem/pm_domain can. Also, recently the > pm_runtime_force* functions were added so that a bus/subsystem could do > this easily. That's okay; if a subsystem calls one of those functions then we know it intends to work around the usual protections. > > It sounds like what you really want for these devices is to have > > dev->power.is_suspended get set at the start of > > __device_suspend_late() rather than at the end of __device_suspend(). > > Or maybe even not to get set at all. > > Well, from my PoV, power.is_suspended doesn't have any meaning for > runtime PM. It's only for system suspend. If it doesn't have any meaning for runtime PM, it shouldn't be tested in runtime.c. But never mind that; the is_suspended flag is a red herring. It doesn't have clearly defined semantics. What we really need to figure out is how to tell the PM core which devices may safely have their runtime callbacks invoked during system suspend. For those devices, the core can avoid calling pm_runtime_disable() during the suspend_late phase. That would address your requirements, right? Here's another way to think about it. At some point during system suspend, a device needs to powered down for the last time. Many subsystems/drivers do this in their ->suspend callback. Some during ->suspend_late or ->suspend_irq. Some may never do it explicitly. Regardless, the PM core needs to know when it has happened, so that it can block ->runtime_resume callbacks from that point onward. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: fbdev: skeletonfb.c: Adding code to managing allocation error
(Adding Geert, who probably wrote most of this
and likely might have forgotten all of it)
On Sat, 2014-06-21 at 15:17 +0200, Rickard Strandqvist wrote:
> Adding missing code for managing a memory allocation error that may occur.
>
> This was partly found using a static code analysis program called cppcheck.
skeletonfb.c is not meant to be compiled.
It's a sample driver template.
Those /* goto error path */ lines are for
driver writers that use this to figure out
what to do.
The second return is not correct as it would
not free the first alloc'd block.
> diff --git a/drivers/video/fbdev/skeletonfb.c
> b/drivers/video/fbdev/skeletonfb.c
[]
> @@ -692,6 +692,7 @@ static int xxxfb_probe(struct pci_dev *dev, const struct
> pci_device_id *ent)
>
> if (!info) {
> /* goto error path */
> + return -ENOMEM;
> }
>
> par = info->par;
> @@ -746,6 +747,7 @@ static int xxxfb_probe(struct pci_dev *dev, const struct
> pci_device_id *ent)
> info->pixmap.addr = kmalloc(PIXMAP_SIZE, GFP_KERNEL);
> if (!info->pixmap.addr) {
> /* goto error */
> + return -ENOMEM;
> }
>
> info->pixmap.size = PIXMAP_SIZE;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] net/dsa/dsa.c: remove null test before kfree
On Sat, 2014-06-21 at 11:36 +0200, Fabian Frederick wrote:
> On Sat, 21 Jun 2014 10:37:24 +0200 Bjørn Mork wrote:
> > On 20 June 2014 22:36:47 CEST, Fabian Frederick wrote:
> > > Fix checkpatch warning:
> > > WARNING: kfree(NULL) is safe this check is probably not required
> >
> > "probably not" implies that there are cases where the check *is*
> > required. That means that your commit message should explain why
> > this particular check is redundant.
> >
> > I haven't analyzed your changes here, so they could be fine for all
> > I know. My point is that such analysis is your job when submitting
> > cleanups like this one.
> AFAIK, any
>
> if(foo)
> kfree(foo)
>
> can be updated to kfree(foo) but
>
> if (foo){
> kfree(foo)
> do something else
> }
>
> has to be evaluated ; reason for the "probably" in warning message.
> If I'm wrong maybe we could be more verbose in checkpatch :)
I think Bjørn is correct here.
Just because checkpatch bleats some message or another,
it's still the submitter's job to validate the code.
In this case, it seems the simple substitution of
"unnecessary null" to the subject would have been
enough validation.
I don't think checkpatch needs updating for this, but
maybe you could propose better language.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/3] Add Rockchip Soc PWM driver
This series adds support for the PWM controller found on Rockchip RK29, RK30 and RK31 SoCs. It is based on the documentation publicly available [0] and kernel sources from Rockchip [1] and has been tested on RK3188. The last patch, which adds device tree nodes in the dts, depends on the clocks introduced by Heiko in his recent submission of a new clk driver for Rockchip RK3188. [0] http://dl.radxa.com/rock/docs/hw/ds/Rockchip%20RK30xx%20TRM%20V2.0.pdf [1] https://github.com/rkchrome/kernel Changes in v2: * address comments from Thierry Reding: - remove dependency on OF - use NSEC_PER_SEC from time.h - fix MODULE_DEVICE_TABLE name - make pwm_ops struct const - indentation and cosmetics Beniamino Galvani (3): pwm: add Rockchip SoC PWM support pwm: rockchip: document device tree bindings ARM: dts: rk3xxx: add PWM nodes .../devicetree/bindings/pwm/pwm-rockchip.txt | 17 ++ arch/arm/boot/dts/rk3188.dtsi | 40 + arch/arm/boot/dts/rk3xxx.dtsi | 32 drivers/pwm/Kconfig|7 + drivers/pwm/Makefile |1 + drivers/pwm/pwm-rockchip.c | 177 6 files changed, 274 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt create mode 100644 drivers/pwm/pwm-rockchip.c -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] ARM: dts: rk3xxx: add PWM nodes
This adds PWM nodes to the Rockchip device trees.
Signed-off-by: Beniamino Galvani
---
arch/arm/boot/dts/rk3188.dtsi | 40
arch/arm/boot/dts/rk3xxx.dtsi | 32
2 files changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index a50a462..a91e205 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -114,6 +114,22 @@
clock-names = "biu", "ciu";
};
+ pwm0: pwm@2003 {
+ clocks = <&cru PCLK_PWM01>;
+ };
+
+ pwm1: pwm@20030010 {
+ clocks = <&cru PCLK_PWM01>;
+ };
+
+ pwm2: pwm@20050020 {
+ clocks = <&cru PCLK_PWM23>;
+ };
+
+ pwm3: pwm@20050030 {
+ clocks = <&cru PCLK_PWM23>;
+ };
+
cru: cru@2000 {
compatible = "rockchip,rk3188-cru";
reg = <0x2000 0x1000>;
@@ -310,6 +326,30 @@
;
};
};
+
+ pwm0 {
+ pwm0_pins: pwm0-pins {
+ rockchip,pins = ;
+ };
+ };
+
+ pwm1 {
+ pwm1_pins: pwm1-pins {
+ rockchip,pins = ;
+ };
+ };
+
+ pwm2 {
+ pwm2_pins: pwm2-pins {
+ rockchip,pins = ;
+ };
+ };
+
+ pwm3 {
+ pwm3_pins: pwm3-pins {
+ rockchip,pins = ;
+ };
+ };
};
};
};
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index 2adf1cc9e..80811bb 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -135,5 +135,37 @@
status = "disabled";
};
+
+ pwm0: pwm@2003 {
+ compatible = "rockchip,rk2928-pwm";
+ reg = <0x2003 0x10>;
+ #pwm-cells = <2>;
+ clocks = <&clk_gates7 10>;
+ status = "disabled";
+ };
+
+ pwm1: pwm@20030010 {
+ compatible = "rockchip,rk2928-pwm";
+ reg = <0x20030010 0x10>;
+ #pwm-cells = <2>;
+ clocks = <&clk_gates7 10>;
+ status = "disabled";
+ };
+
+ pwm2: pwm@20050020 {
+ compatible = "rockchip,rk2928-pwm";
+ reg = <0x20050020 0x10>;
+ #pwm-cells = <2>;
+ clocks = <&clk_gates7 11>;
+ status = "disabled";
+ };
+
+ pwm3: pwm@20050030 {
+ compatible = "rockchip,rk2928-pwm";
+ reg = <0x20050030 0x10>;
+ #pwm-cells = <2>;
+ clocks = <&clk_gates7 11>;
+ status = "disabled";
+ };
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] pwm: rockchip: document device tree bindings
This adds binding documentation for Rockchip SoC PWM driver.
Signed-off-by: Beniamino Galvani
---
.../devicetree/bindings/pwm/pwm-rockchip.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
new file mode 100644
index 000..3182126
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
@@ -0,0 +1,17 @@
+Rockchip PWM controller
+
+Required properties:
+ - compatible: should be "rockchip,rk2928-pwm"
+ - reg: physical base address and length of the controller's registers
+ - clocks: phandle and clock specifier of the PWM reference clock
+ - #pwm-cells: should be 2. See pwm.txt in this directory for a
+ description of the cell format.
+
+Example:
+
+ pwm0: pwm@2003 {
+ compatible = "rockchip,rk2928-pwm";
+ reg = <0x2003 0x10>;
+ clocks = <&cru PCLK_PWM01>;
+ #pwm-cells = <2>;
+ };
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] pwm: add Rockchip SoC PWM support
This commit adds a driver for the PWM controller found on Rockchip
RK29, RK30 and RK31 SoCs.
Signed-off-by: Beniamino Galvani
---
drivers/pwm/Kconfig|7 ++
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-rockchip.c | 177
3 files changed, 185 insertions(+)
create mode 100644 drivers/pwm/pwm-rockchip.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 4ad7b89..a86879a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -206,6 +206,13 @@ config PWM_RENESAS_TPU
To compile this driver as a module, choose M here: the module
will be called pwm-renesas-tpu.
+config PWM_ROCKCHIP
+ tristate "Rockchip PWM support"
+ depends on ARCH_ROCKCHIP
+ help
+ Generic PWM framework driver for the PWM controller found on
+ Rockchip SoCs.
+
config PWM_SAMSUNG
tristate "Samsung PWM support"
depends on PLAT_SAMSUNG
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 5c86a19..e03e2ae 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o
+obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
obj-$(CONFIG_PWM_SPEAR)+= pwm-spear.o
obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
new file mode 100644
index 000..eec2145
--- /dev/null
+++ b/drivers/pwm/pwm-rockchip.c
@@ -0,0 +1,177 @@
+/*
+ * PWM driver for Rockchip SoCs
+ *
+ * Copyright (C) 2014 Beniamino Galvani
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PWM_CNTR 0x00/* Counter register */
+#define PWM_HRC0x04/* High reference
register */
+#define PWM_LRC0x08/* Low reference
register */
+#define PWM_CTRL 0x0c/* Control register */
+#define PWM_CTRL_TIMER_EN (1 << 0)
+#define PWM_CTRL_OUTPUT_EN (1 << 3)
+
+#define PRESCALER 2
+
+struct rockchip_pwm_chip {
+ struct pwm_chip chip;
+ struct clk *clk;
+ void __iomem *base;
+};
+
+static inline struct rockchip_pwm_chip *to_rockchip_pwm_chip(struct pwm_chip
*c)
+{
+ return container_of(c, struct rockchip_pwm_chip, chip);
+}
+
+static int rockchip_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+ unsigned long period, duty;
+ u64 clk_rate, div;
+ int ret;
+
+ clk_rate = clk_get_rate(pc->clk);
+
+ /*
+* Since period and duty cycle registers have a width of 32
+* bits, every possible input period can be obtained using the
+* default prescaler value for all practical clock rate values.
+*/
+ div = clk_rate * period_ns;
+ do_div(div, PRESCALER * NSEC_PER_SEC);
+ period = div;
+
+ div = clk_rate * duty_ns;
+ do_div(div, PRESCALER * NSEC_PER_SEC);
+ duty = div;
+
+ ret = clk_enable(pc->clk);
+ if (ret)
+ return ret;
+
+ writel(period, pc->base + PWM_LRC);
+ writel(duty, pc->base + PWM_HRC);
+ writel(0, pc->base + PWM_CNTR);
+
+ clk_disable(pc->clk);
+
+ return 0;
+}
+
+static int rockchip_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+ int ret;
+ u32 val;
+
+ ret = clk_enable(pc->clk);
+ if (ret)
+ return ret;
+
+ val = readl_relaxed(pc->base + PWM_CTRL);
+ val |= PWM_CTRL_OUTPUT_EN | PWM_CTRL_TIMER_EN;
+ writel_relaxed(val, pc->base + PWM_CTRL);
+
+ return 0;
+}
+
+static void rockchip_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+ u32 val;
+
+ val = readl_relaxed(pc->base + PWM_CTRL);
+ val &= ~(PWM_CTRL_OUTPUT_EN | PWM_CTRL_TIMER_EN);
+ writel_relaxed(val, pc->base + PWM_CTRL);
+
+ clk_disable(pc->clk);
+}
+
+static const struct pwm_ops rockchip_pwm_ops = {
+ .config = rockchip_pwm_config,
+ .enable = rockchip_pwm_enable,
+ .disable = rockchip_pwm_disable,
+ .owner = THIS_MODULE,
+};
+
+static int rockchip_pwm_probe(struct platform_device *pdev)
+{
+ struct rockchip_pwm_chip *pc;
+ struct resource *r;
+ int ret;
+
+ pc = devm_k
[PATCH] x86_32,signal: Fix vdso rt_sigreturn
This commit: commit 6f121e548f83674ab4920a4e60afb58d4f61b829 Author: Andy Lutomirski Date: Mon May 5 12:19:34 2014 -0700 x86, vdso: Reimplement vdso.so preparation in build-time C Contained this obvious typo: - restorer = VDSO32_SYMBOL(current->mm->context.vdso, rt_sigreturn); + restorer = current->mm->context.vdso + + selected_vdso32->sym___kernel_sigreturn; Note the missing 'rt_' in the new code. Fix it. Signed-off-by: Andy Lutomirski --- Compile-tested only. I bet that someone will test it here far more quickly than I can figure out how to test it: https://bugzilla.redhat.com/show_bug.cgi?id=1110968 arch/x86/kernel/signal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c index a0da58d..2851d63 100644 --- a/arch/x86/kernel/signal.c +++ b/arch/x86/kernel/signal.c @@ -363,7 +363,7 @@ static int __setup_rt_frame(int sig, struct ksignal *ksig, /* Set up to return from userspace. */ restorer = current->mm->context.vdso + - selected_vdso32->sym___kernel_sigreturn; + selected_vdso32->sym___kernel_rt_sigreturn; if (ksig->ka.sa.sa_flags & SA_RESTORER) restorer = ksig->ka.sa.sa_restorer; put_user_ex(restorer, &frame->pretcode); -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/11 v2] tlan: Link handling improvements and Olicom fixes
This patch series improves link handling in tlan driver, allowing the cable to be (un)plugged anytime and NetworkManager to work properly. Also there are some bugfixes related to Olicom OC-2326 card. -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/11] tlan: Add PHY reset timeout
Add a timeout to prevent infinite loop waiting for PHY to reset.
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/ti/tlan.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index b4e9dcf..f5af196 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -2569,6 +2569,7 @@ static void tlan_phy_reset(struct net_device *dev)
struct tlan_priv*priv = netdev_priv(dev);
u16 phy;
u16 value;
+ unsigned long timeout = jiffies + HZ;
phy = priv->phy[priv->phy_num];
@@ -2576,9 +2577,13 @@ static void tlan_phy_reset(struct net_device *dev)
tlan_mii_sync(dev->base_addr);
value = MII_GC_LOOPBK | MII_GC_RESET;
tlan_mii_write_reg(dev, phy, MII_GEN_CTL, value);
- tlan_mii_read_reg(dev, phy, MII_GEN_CTL, &value);
- while (value & MII_GC_RESET)
+ do {
tlan_mii_read_reg(dev, phy, MII_GEN_CTL, &value);
+ if (time_after(jiffies, timeout)) {
+ netdev_err(dev, "PHY reset timeout\n");
+ return;
+ }
+ } while (value & MII_GC_RESET);
/* Wait for 500 ms and initialize.
* I don't remember why I wait this long.
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/11] tlan: Don't scream if no link
Remove excess printks when the link is down.
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/ti/tlan.c |9 -
drivers/net/ethernet/ti/tlan.h |1 -
2 files changed, 10 deletions(-)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index 47eb30e..6d9898f 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -1199,9 +1199,6 @@ static irqreturn_t tlan_handle_interrupt(int irq, void
*dev_id)
static int tlan_close(struct net_device *dev)
{
- struct tlan_priv *priv = netdev_priv(dev);
-
- priv->neg_be_verbose = 0;
tlan_stop(dev);
free_irq(dev->irq, dev);
@@ -2702,12 +2699,6 @@ static void tlan_phy_finish_auto_neg(struct net_device
*dev)
/* Wait for 8 sec to give the process
* more time. Perhaps we should fail after a while.
*/
- if (!priv->neg_be_verbose++) {
- pr_info("Giving autonegotiation more time.\n");
- pr_info("Please check that your adapter has\n");
- pr_info("been properly connected to a HUB or
Switch.\n");
- pr_info("Trying to establish link in the
background...\n");
- }
tlan_set_timer(dev, (8*HZ), TLAN_TIMER_PHY_FINISH_AN);
return;
}
diff --git a/drivers/net/ethernet/ti/tlan.h b/drivers/net/ethernet/ti/tlan.h
index b6ceeba..e992841 100644
--- a/drivers/net/ethernet/ti/tlan.h
+++ b/drivers/net/ethernet/ti/tlan.h
@@ -208,7 +208,6 @@ struct tlan_priv {
u8 tlan_full_duplex;
spinlock_t lock;
struct work_struct tlan_tqueue;
- u8 neg_be_verbose;
};
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/11] tlan: Enable link monitoring
Enable old link monitoring code and modify it:
- control LINK LED
- use separate timer so it does not interfere with ACT LED
Tested with Olicom OC-2326.
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/ti/tlan.c | 115 +---
drivers/net/ethernet/ti/tlan.h |3 +-
2 files changed, 49 insertions(+), 69 deletions(-)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index e7449cb..c75ad6b 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -69,10 +69,6 @@ MODULE_AUTHOR("Maintainer: Samuel Chessman
");
MODULE_DESCRIPTION("Driver for TI ThunderLAN based ethernet PCI adapters");
MODULE_LICENSE("GPL");
-
-/* Define this to enable Link beat monitoring */
-#undef MONITOR
-
/* Turn on debugging. See Documentation/networking/tlan.txt for details */
static intdebug;
module_param(debug, int, 0);
@@ -194,9 +190,7 @@ static void tlan_phy_power_up(struct net_device *);
static voidtlan_phy_reset(struct net_device *);
static voidtlan_phy_start_link(struct net_device *);
static voidtlan_phy_finish_auto_neg(struct net_device *);
-#ifdef MONITOR
-static void tlan_phy_monitor(struct net_device *);
-#endif
+static void tlan_phy_monitor(unsigned long);
/*
static int tlan_phy_nop(struct net_device *);
@@ -340,6 +334,7 @@ static void tlan_stop(struct net_device *dev)
{
struct tlan_priv *priv = netdev_priv(dev);
+ del_timer_sync(&priv->media_timer);
tlan_read_and_clear_stats(dev, TLAN_RECORD);
outl(TLAN_HC_AD_RST, dev->base_addr + TLAN_HOST_CMD);
/* Reset and power down phy */
@@ -889,6 +884,7 @@ static int tlan_open(struct net_device *dev)
}
init_timer(&priv->timer);
+ init_timer(&priv->media_timer);
tlan_start(dev);
@@ -1811,11 +1807,6 @@ static void tlan_timer(unsigned long data)
priv->timer.function = NULL;
switch (priv->timer_type) {
-#ifdef MONITOR
- case TLAN_TIMER_LINK_BEAT:
- tlan_phy_monitor(dev);
- break;
-#endif
case TLAN_TIMER_PHY_PDOWN:
tlan_phy_power_down(dev);
break;
@@ -1859,8 +1850,6 @@ static void tlan_timer(unsigned long data)
}
-
-
/*
**
@@ -2258,42 +2247,39 @@ tlan_finish_reset(struct net_device *dev)
tlan_mii_read_reg(dev, phy, MII_GEN_STS, &status);
udelay(1000);
tlan_mii_read_reg(dev, phy, MII_GEN_STS, &status);
- if ((status & MII_GS_LINK) &&
- /* We only support link info on Nat.Sem. PHY's */
- (tlphy_id1 == NAT_SEM_ID1) &&
- (tlphy_id2 == NAT_SEM_ID2)) {
- tlan_mii_read_reg(dev, phy, MII_AN_LPA, &partner);
- tlan_mii_read_reg(dev, phy, TLAN_TLPHY_PAR, &tlphy_par);
-
- netdev_info(dev,
- "Link active with %s %uMbps %s-Duplex\n",
- !(tlphy_par & TLAN_PHY_AN_EN_STAT)
- ? "forced" : "Autonegotiation enabled,",
- tlphy_par & TLAN_PHY_SPEED_100
- ? 100 : 10,
- tlphy_par & TLAN_PHY_DUPLEX_FULL
- ? "Full" : "Half");
-
- if (tlphy_par & TLAN_PHY_AN_EN_STAT) {
- netdev_info(dev, "Partner capability:");
- for (i = 5; i < 10; i++)
- if (partner & (1 << i))
- pr_cont(" %s", media[i-5]);
- pr_cont("\n");
- }
-
- tlan_dio_write8(dev->base_addr, TLAN_LED_REG,
- TLAN_LED_LINK);
-#ifdef MONITOR
- /* We have link beat..for now anyway */
- priv->link = 1;
- /*Enabling link beat monitoring */
- tlan_set_timer(dev, (10*HZ), TLAN_TIMER_LINK_BEAT);
-#endif
- } else if (status & MII_GS_LINK) {
- netdev_info(dev, "Link active\n");
- tlan_dio_write8(dev->base_addr, TLAN_LED_REG,
- TLAN_LED_LINK);
+ if (status & MII_GS_LINK) {
+ /* We only support link info on Nat.Sem. PHY's */
+ if ((tlphy_id1 == NAT_SEM_ID1) &&
+ (tlphy_id2 == NAT_SEM_ID2)) {
+ tlan_mii_read_reg(dev, phy, MII_AN_LPA,
+ &partner);
+ tlan_mii
[PATCH 09/11] tlan: Don't disable internal PHY on cards that use it in 10 Mbps mode
In tlan_reset_adapter, we disable internal PHY when an external one is used.
On cards which use internal PHY in 10 Mbps mode, we enable it later when
setting 10 Mbps mode but it does not really work (PHY fails to reset).
Leave it enabled instead.
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/ti/tlan.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index f5af196..ef32e5f 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -2238,7 +2238,9 @@ tlan_reset_adapter(struct net_device *dev)
}
}
- if (priv->phy_num == 0)
+ /* don't power down internal PHY if we're going to use it */
+ if (priv->phy_num == 0 ||
+ (priv->adapter->flags & TLAN_ADAPTER_USE_INTERN_10))
data |= TLAN_NET_CFG_PHY_EN;
tlan_dio_write16(dev->base_addr, TLAN_NET_CONFIG, (u16) data);
@@ -2689,7 +2691,6 @@ static void tlan_phy_finish_auto_neg(struct net_device
*dev)
struct tlan_priv*priv = netdev_priv(dev);
u16 an_adv;
u16 an_lpa;
- u16 data;
u16 mode;
u16 phy;
u16 status;
@@ -2722,9 +2723,6 @@ static void tlan_phy_finish_auto_neg(struct net_device
*dev)
(priv->adapter->flags & TLAN_ADAPTER_USE_INTERN_10) &&
(priv->phy_num != 0)) {
priv->phy_num = 0;
- data = TLAN_NET_CFG_1FRAG | TLAN_NET_CFG_1CHAN
- | TLAN_NET_CFG_PHY_EN;
- tlan_dio_write16(dev->base_addr, TLAN_NET_CONFIG, data);
tlan_set_timer(dev, (400*HZ/1000), TLAN_TIMER_PHY_PDOWN);
return;
}
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/11] tlan: Fix MAC address byte order on OC-2325/OC-2326
Olicom OC-2325 and OC-2326 cards have the MAC address byte-swapped in EEPROM.
Byte-swap the MAC address if it's located at offset 0xF8.
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/ti/tlan.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index ae9fece..31d4a96 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -864,7 +864,7 @@ static int tlan_init(struct net_device *dev)
priv->rx_list_dma + sizeof(struct tlan_list)*TLAN_NUM_RX_LISTS;
err = 0;
- for (i = 0; i < 6 ; i++)
+ for (i = 0; i < ETH_ALEN; i++)
err |= tlan_ee_read_byte(dev,
(u8) priv->adapter->addr_ofs + i,
(u8 *) &dev->dev_addr[i]);
@@ -872,7 +872,14 @@ static int tlan_init(struct net_device *dev)
pr_err("%s: Error reading MAC from eeprom: %d\n",
dev->name, err);
}
- dev->addr_len = 6;
+ /* Olicom OC-2325/OC-2326 have the address byte-swapped */
+ if (priv->adapter->addr_ofs == 0xf8) {
+ for (i = 0; i < ETH_ALEN; i += 2) {
+ char tmp = dev->dev_addr[i];
+ dev->dev_addr[i] = dev->dev_addr[i + 1];
+ dev->dev_addr[i + 1] = tmp;
+ }
+ }
netif_carrier_off(dev);
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/11] tlan: Make autonegotiation faster
Reduce the autonegotiation poll interval from 8 seconds to 2. This greatly reduces the time needed to detect link presence, especially on Olicom cards at 10 Mbps (two autonegoatiations required). Signed-off-by: Ondrej Zary --- drivers/net/ethernet/ti/tlan.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c index 6d9898f..b4e9dcf 100644 --- a/drivers/net/ethernet/ti/tlan.c +++ b/drivers/net/ethernet/ti/tlan.c @@ -2699,7 +2699,7 @@ static void tlan_phy_finish_auto_neg(struct net_device *dev) /* Wait for 8 sec to give the process * more time. Perhaps we should fail after a while. */ - tlan_set_timer(dev, (8*HZ), TLAN_TIMER_PHY_FINISH_AN); + tlan_set_timer(dev, 2 * HZ, TLAN_TIMER_PHY_FINISH_AN); return; } -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/11] tlan: Restart autonegotiation on link loss
When link is lost on a card which uses internal PHY for 10 Mbit speeds,
restart autonegotiation to allow switching between 10 and 100 Mbps speeds.
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/ti/tlan.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index 31d4a96..47eb30e 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -2721,6 +2721,7 @@ static void tlan_phy_finish_auto_neg(struct net_device
*dev)
else if (!(mode & 0x0080) && (mode & 0x0040))
priv->tlan_full_duplex = true;
+ /* switch to internal PHY for 10 Mbps */
if ((!(mode & 0x0180)) &&
(priv->adapter->flags & TLAN_ADAPTER_USE_INTERN_10) &&
(priv->phy_num != 0)) {
@@ -2788,6 +2789,20 @@ static void tlan_phy_monitor(unsigned long data)
dev->name);
tlan_dio_write8(dev->base_addr, TLAN_LED_REG, 0);
netif_carrier_off(dev);
+ if (priv->adapter->flags & TLAN_ADAPTER_USE_INTERN_10) {
+ /* power down internal PHY */
+ u16 data = MII_GC_PDOWN | MII_GC_LOOPBK |
+ MII_GC_ISOLATE;
+ tlan_mii_sync(dev->base_addr);
+ tlan_mii_write_reg(dev, priv->phy[0],
+ MII_GEN_CTL, data);
+ /* set to external PHY */
+ priv->phy_num = 1;
+ /* restart autonegotiation */
+ tlan_set_timer(dev, 4 * HZ / 10,
+ TLAN_TIMER_PHY_PDOWN);
+ return;
+ }
}
}
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/11] tlan: Enable activity LED on Olicom OC-2325 and OC-2326
Olicom OC-2325 and OC-2326 ethernet cards have an activity LED but it does not
work with tlan driver as it's not enabled. Enable it.
Tested with OC-2326.
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/ti/tlan.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index 591437e..e7449cb 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -107,8 +107,10 @@ static struct board {
{ "Compaq Netelligent 10/100 TX Embedded UTP",
TLAN_ADAPTER_NONE, 0x83 },
{ "Olicom OC-2183/2185", TLAN_ADAPTER_USE_INTERN_10, 0x83 },
- { "Olicom OC-2325", TLAN_ADAPTER_UNMANAGED_PHY, 0xf8 },
- { "Olicom OC-2326", TLAN_ADAPTER_USE_INTERN_10, 0xf8 },
+ { "Olicom OC-2325", TLAN_ADAPTER_ACTIVITY_LED |
+ TLAN_ADAPTER_UNMANAGED_PHY, 0xf8 },
+ { "Olicom OC-2326", TLAN_ADAPTER_ACTIVITY_LED |
+ TLAN_ADAPTER_USE_INTERN_10, 0xf8 },
{ "Compaq Netelligent 10/100 TX UTP", TLAN_ADAPTER_ACTIVITY_LED, 0x83 },
{ "Compaq Netelligent 10 T/2 PCI UTP/coax", TLAN_ADAPTER_NONE, 0x83 },
{ "Compaq NetFlex-3/E",
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/11] tlan: Add ethtool support
Add basic ethtool support to tlan driver:
- driver info - link detect (this allows NetworkManager to detect carrier)
- EEPROM read
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/ti/tlan.c | 37 +
drivers/net/ethernet/ti/tlan.h |1 +
2 files changed, 38 insertions(+)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index c75ad6b..ae9fece 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -779,7 +779,43 @@ static const struct net_device_ops tlan_netdev_ops = {
#endif
};
+static void tlan_get_drvinfo(struct net_device *dev,
+struct ethtool_drvinfo *info)
+{
+ struct tlan_priv *priv = netdev_priv(dev);
+
+ strlcpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
+ if (priv->pci_dev)
+ strlcpy(info->bus_info, pci_name(priv->pci_dev),
+ sizeof(info->bus_info));
+ else
+ strlcpy(info->bus_info, "EISA", sizeof(info->bus_info));
+ info->eedump_len = TLAN_EEPROM_SIZE;
+}
+
+static int tlan_get_eeprom_len(struct net_device *dev)
+{
+ return TLAN_EEPROM_SIZE;
+}
+static int tlan_get_eeprom(struct net_device *dev,
+ struct ethtool_eeprom *eeprom, u8 *data)
+{
+ int i;
+
+ for (i = 0; i < TLAN_EEPROM_SIZE; i++)
+ if (tlan_ee_read_byte(dev, i, &data[i]))
+ return -EIO;
+
+ return 0;
+}
+
+static const struct ethtool_ops tlan_ethtool_ops = {
+ .get_drvinfo= tlan_get_drvinfo,
+ .get_link = ethtool_op_get_link,
+ .get_eeprom_len = tlan_get_eeprom_len,
+ .get_eeprom = tlan_get_eeprom,
+};
/***
* tlan_init
@@ -842,6 +878,7 @@ static int tlan_init(struct net_device *dev)
/* Device methods */
dev->netdev_ops = &tlan_netdev_ops;
+ dev->ethtool_ops = &tlan_ethtool_ops;
dev->watchdog_timeo = TX_TIMEOUT;
return 0;
diff --git a/drivers/net/ethernet/ti/tlan.h b/drivers/net/ethernet/ti/tlan.h
index 4ced905..b6ceeba 100644
--- a/drivers/net/ethernet/ti/tlan.h
+++ b/drivers/net/ethernet/ti/tlan.h
@@ -240,6 +240,7 @@ struct tlan_priv {
#define TLAN_EEPROM_ACK0
#define TLAN_EEPROM_STOP 1
+#define TLAN_EEPROM_SIZE 256
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 7/9] xen: Put EFI machinery in place
On Fri, 20 Jun 2014, Daniel Kiper wrote:
> This patch enables EFI usage under Xen dom0. Standard EFI Linux
> Kernel infrastructure cannot be used because it requires direct
> access to EFI data and code. However, in dom0 case it is not possible
> because above mentioned EFI stuff is fully owned and controlled
> by Xen hypervisor. In this case all calls from dom0 to EFI must
> be requested via special hypercall which in turn executes relevant
> EFI code in behalf of dom0.
>
> When dom0 kernel boots it checks for EFI availability on a machine.
> If it is detected then artificial EFI system table is filled.
> Native EFI callas are replaced by functions which mimics them
> by calling relevant hypercall. Later pointer to EFI system table
> is passed to standard EFI machinery and it continues EFI subsystem
> initialization taking into account that there is no direct access
> to EFI boot services, runtime, tables, structures, etc. After that
> system runs as usual.
>
> This patch is based on Jan Beulich and Tang Liang work.
>
> Signed-off-by: Jan Beulich
> Signed-off-by: Tang Liang
> Signed-off-by: Daniel Kiper
> ---
> v6 - suggestions/fixes:
>- remove unneeded BUG() call
> (suggested by Stefano Stabellini).
>
> v5 - suggestions/fixes:
>- improve macro usage readability
> (suggested by Andrew Cooper and David Vrabel),
>- conditions cleanup
> (suggested by David Vrabel),
>- use -fshort-wchar option
> (suggested by Jan Beulich),
>- Kconfig rule cleanup
> (suggested by Jan Beulich),
>- forward port fixes from SUSE kernel
> (suggested by Jan Beulich),
>- improve commit message
> (suggested by David Vrabel).
>
> v4 - suggestions/fixes:
>- "just populate an efi_system_table_t object"
> (suggested by Matt Fleming).
> ---
> arch/x86/xen/enlighten.c | 24 +++
> drivers/xen/Kconfig |4 +
> drivers/xen/Makefile |3 +
> drivers/xen/efi.c| 367
> ++
> 4 files changed, 398 insertions(+)
> create mode 100644 drivers/xen/efi.c
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index ffb101e..04611ea 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -150,6 +151,15 @@ struct shared_info *HYPERVISOR_shared_info =
> &xen_dummy_shared_info;
> */
> static int have_vcpu_info_placement = 1;
>
> +#ifdef CONFIG_XEN_EFI
> +extern efi_system_table_t __init *xen_efi_probe(void);
> +#else
> +static efi_system_table_t __init *xen_efi_probe(void)
> +{
> + return NULL;
> +}
> +#endif
I should have spotted this before, but it would be better to move this
chunk to an header file under include/xen.
> struct tls_descs {
> struct desc_struct desc[3];
> };
> @@ -1520,6 +1530,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
> {
> struct physdev_set_iopl set_iopl;
> int rc;
> + efi_system_table_t *efi_systab_xen;
>
> if (!xen_start_info)
> return;
> @@ -1718,6 +1729,19 @@ asmlinkage __visible void __init xen_start_kernel(void)
>
> xen_setup_runstate_info(0);
>
> + efi_systab_xen = xen_efi_probe();
> +
> + if (efi_systab_xen) {
> + strncpy((char *)&boot_params.efi_info.efi_loader_signature,
> "Xen",
> +
> sizeof(boot_params.efi_info.efi_loader_signature));
> + boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
> + boot_params.efi_info.efi_systab_hi =
> (__u32)(__pa(efi_systab_xen) >> 32);
> +
> + set_bit(EFI_BOOT, &efi.flags);
> + set_bit(EFI_PARAVIRT, &efi.flags);
> + set_bit(EFI_64BIT, &efi.flags);
> + }
> +
> /* Start the world */
> #ifdef CONFIG_X86_32
> i386_start_kernel();
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 38fb36e..8bc0183 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -240,4 +240,8 @@ config XEN_MCE_LOG
> config XEN_HAVE_PVMMU
> bool
>
> +config XEN_EFI
> + def_bool y
> + depends on X86_64 && EFI
> +
> endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 45e00af..84044b5 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -9,6 +9,8 @@ obj-y += xenbus/
> nostackp := $(call cc-option, -fno-stack-protector)
> CFLAGS_features.o:= $(nostackp)
>
> +CFLAGS_efi.o += -fshort-wchar
> +
> dom0-$(CONFIG_PCI) += pci.o
> dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
> dom0-$(CONFIG_ACPI) += acpi.o $(xen-pad-y)
> @@ -33,6 +35,7 @@ obj-$(CONFIG_XEN_STUB) += xen-stub.o
> obj-$(CONFIG_XEN_ACPI_HOTPLUG_MEMORY)+= xen-acpi-memhotplug.o
> obj-$(CONFIG_XEN_ACPI_HOTPLUG_CPU) += xen-acpi-cpuhotplug.o
> obj-$(CONFIG_XEN_ACPI_PROCESSOR) += xen-acpi-processor.o
> +obj
[PATCH] staging: wlags49_h2: Fix use of skb after netif_rx
This patch moves a call to netif_rx(skb) after a subsequent reference to
skb, because netif_rx may call kfree_skb via enqueue_to_backlog on its
argument.
This was found using the following semantic match.
//
@@
expression skb, e,e1;
@@
(
netif_rx(skb);
|
netif_rx_ni(skb);
)
... when != skb = e
(
skb = e1
|
* skb
)
//
Signed-off-by: Himangi Saraogi
Acked-by: Julia Lawall
---
drivers/staging/wlags49_h2/wl_netdev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/wlags49_h2/wl_netdev.c
b/drivers/staging/wlags49_h2/wl_netdev.c
index a10d014..60701d43 100644
--- a/drivers/staging/wlags49_h2/wl_netdev.c
+++ b/drivers/staging/wlags49_h2/wl_netdev.c
@@ -888,8 +888,6 @@ int wl_rx(struct net_device *dev)
GET_PACKET(skb->dev, skb, pktlen);
if (status == HCF_SUCCESS) {
- netif_rx(skb);
-
if (port == 0) {
lp->stats.rx_packets++;
lp->stats.rx_bytes += pktlen;
@@ -918,6 +916,7 @@ int wl_rx(struct net_device *dev)
}
#endif /* WIRELESS_SPY */
#endif /* WIRELESS_EXT */
+ netif_rx(skb);
} else {
DBG_ERROR(DbgInfo,
"Rx request to card
FAILED\n");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/11] tlan: Isolate external PHY when using internal PHY
When using internal 10 Mbps PHY, isolate the external PHY from MII bus.
External PHY must be kept powered up because it passes TX from tlan chip to
network.
This fixes weird link-loss problems under load with OC-2326 card at 10 Mbps.
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/ti/tlan.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index 3c88ac2..89de65e 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -2529,9 +2529,10 @@ static void tlan_phy_power_down(struct net_device *dev)
value = MII_GC_PDOWN | MII_GC_LOOPBK | MII_GC_ISOLATE;
tlan_mii_sync(dev->base_addr);
tlan_mii_write_reg(dev, priv->phy[priv->phy_num], MII_GEN_CTL, value);
- if ((priv->phy_num == 0) &&
- (priv->phy[1] != TLAN_PHY_NONE) &&
- (!(priv->adapter->flags & TLAN_ADAPTER_USE_INTERN_10))) {
+ if ((priv->phy_num == 0) && (priv->phy[1] != TLAN_PHY_NONE)) {
+ /* if using internal PHY, the external PHY must be powered on */
+ if (priv->adapter->flags & TLAN_ADAPTER_USE_INTERN_10)
+ value = MII_GC_ISOLATE; /* just isolate it from MII */
tlan_mii_sync(dev->base_addr);
tlan_mii_write_reg(dev, priv->phy[1], MII_GEN_CTL, value);
}
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/11] tlan: Enable device at resume
pci_disable_device() is called in _suspend but there's no corresponding
pci_enable_device() in _resume.
This causes "disabling already-disabled device" warning on 2nd suspend.
Add pci_enable_device() call to _resume to fix this problem.
Signed-off-by: Ondrej Zary
---
drivers/net/ethernet/ti/tlan.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index ef32e5f..3c88ac2 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -366,8 +366,10 @@ static int tlan_suspend(struct pci_dev *pdev, pm_message_t
state)
static int tlan_resume(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
+ int rc = pci_enable_device(pdev);
- pci_set_power_state(pdev, PCI_D0);
+ if (rc)
+ return rc;
pci_restore_state(pdev);
pci_enable_wake(pdev, PCI_D0, 0);
netif_device_attach(dev);
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] i8k: Drop all labels
Labels are known to be wrong for several Dell laptops.
For example, a single fan may be shown as right fan when in reality
it sits on the left side of the chassis. Drop all labels to avoid
such inaccuracies. Users can select labels in the sensors configuration
file instead if desired.
Signed-off-by: Guenter Roeck
---
drivers/char/i8k.c | 47 +--
1 file changed, 13 insertions(+), 34 deletions(-)
diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index 93dcad0..14ca8f0 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -544,20 +544,6 @@ static ssize_t i8k_hwmon_set_pwm(struct device *dev,
return err < 0 ? -EIO : count;
}
-static ssize_t i8k_hwmon_show_label(struct device *dev,
- struct device_attribute *devattr,
- char *buf)
-{
- static const char *labels[3] = {
- "CPU",
- "Left Fan",
- "Right Fan",
- };
- int index = to_sensor_dev_attr(devattr)->index;
-
- return sprintf(buf, "%s\n", labels[index]);
-}
-
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, i8k_hwmon_show_temp, NULL, 0);
static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, i8k_hwmon_show_temp, NULL, 1);
static SENSOR_DEVICE_ATTR(temp3_input, S_IRUGO, i8k_hwmon_show_temp, NULL, 2);
@@ -570,41 +556,34 @@ static SENSOR_DEVICE_ATTR(fan2_input, S_IRUGO,
i8k_hwmon_show_fan, NULL,
I8K_FAN_RIGHT);
static SENSOR_DEVICE_ATTR(pwm2, S_IRUGO | S_IWUSR, i8k_hwmon_show_pwm,
i8k_hwmon_set_pwm, I8K_FAN_RIGHT);
-static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, i8k_hwmon_show_label, NULL, 0);
-static SENSOR_DEVICE_ATTR(fan1_label, S_IRUGO, i8k_hwmon_show_label, NULL, 1);
-static SENSOR_DEVICE_ATTR(fan2_label, S_IRUGO, i8k_hwmon_show_label, NULL, 2);
static struct attribute *i8k_attrs[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr, /* 0 */
- &sensor_dev_attr_temp1_label.dev_attr.attr, /* 1 */
- &sensor_dev_attr_temp2_input.dev_attr.attr, /* 2 */
- &sensor_dev_attr_temp3_input.dev_attr.attr, /* 3 */
- &sensor_dev_attr_temp4_input.dev_attr.attr, /* 4 */
- &sensor_dev_attr_fan1_input.dev_attr.attr, /* 5 */
- &sensor_dev_attr_pwm1.dev_attr.attr,/* 6 */
- &sensor_dev_attr_fan1_label.dev_attr.attr, /* 7 */
- &sensor_dev_attr_fan2_input.dev_attr.attr, /* 8 */
- &sensor_dev_attr_pwm2.dev_attr.attr,/* 9 */
- &sensor_dev_attr_fan2_label.dev_attr.attr, /* 10 */
+ &sensor_dev_attr_temp2_input.dev_attr.attr, /* 1 */
+ &sensor_dev_attr_temp3_input.dev_attr.attr, /* 2 */
+ &sensor_dev_attr_temp4_input.dev_attr.attr, /* 3 */
+ &sensor_dev_attr_fan1_input.dev_attr.attr, /* 4 */
+ &sensor_dev_attr_pwm1.dev_attr.attr,/* 5 */
+ &sensor_dev_attr_fan2_input.dev_attr.attr, /* 6 */
+ &sensor_dev_attr_pwm2.dev_attr.attr,/* 7 */
NULL
};
static umode_t i8k_is_visible(struct kobject *kobj, struct attribute *attr,
int index)
{
- if ((index == 0 || index == 1) &&
- !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP1))
+ if (index == 0 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP1))
return 0;
- if (index == 2 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP2))
+ if (index == 1 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP2))
return 0;
- if (index == 3 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP3))
+ if (index == 2 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP3))
return 0;
- if (index == 4 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP4))
+ if (index == 3 && !(i8k_hwmon_flags & I8K_HWMON_HAVE_TEMP4))
return 0;
- if (index >= 5 && index <= 7 &&
+ if (index >= 4 && index <= 5 &&
!(i8k_hwmon_flags & I8K_HWMON_HAVE_FAN1))
return 0;
- if (index >= 8 && index <= 10 &&
+ if (index >= 6 && index <= 7 &&
!(i8k_hwmon_flags & I8K_HWMON_HAVE_FAN2))
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
