linux-next: manual merge of the idle tree with Linus' tree
Hi Len,
Today's linux-next merge of the idle tree got a conflict in
arch/x86/include/uapi/asm/msr-index.h between commit 2f86dc4cddcb
("intel_pstate: Add support for HWP") from Linus' tree and commit
a8b65b07d753 ("tools/power turbostat: decode MSR_*_PERF_LIMIT_REASONS")
from the idle tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/include/uapi/asm/msr-index.h
index c8aa65d56027,1277934b0d5e..
--- a/arch/x86/include/uapi/asm/msr-index.h
+++ b/arch/x86/include/uapi/asm/msr-index.h
@@@ -152,45 -152,10 +152,49 @@@
#define MSR_CC6_DEMOTION_POLICY_CONFIG0x0668
#define MSR_MC6_DEMOTION_POLICY_CONFIG0x0669
+/* Hardware P state interface */
+#define MSR_PPERF 0x064e
+#define MSR_PERF_LIMIT_REASONS0x064f
+#define MSR_PM_ENABLE 0x0770
+#define MSR_HWP_CAPABILITIES 0x0771
+#define MSR_HWP_REQUEST_PKG 0x0772
+#define MSR_HWP_INTERRUPT 0x0773
+#define MSR_HWP_REQUEST 0x0774
+#define MSR_HWP_STATUS0x0777
+
+/* CPUID.6.EAX */
+#define HWP_BASE_BIT (1<<7)
+#define HWP_NOTIFICATIONS_BIT (1<<8)
+#define HWP_ACTIVITY_WINDOW_BIT (1<<9)
+#define HWP_ENERGY_PERF_PREFERENCE_BIT(1<<10)
+#define HWP_PACKAGE_LEVEL_REQUEST_BIT (1<<11)
+
+/* IA32_HWP_CAPABILITIES */
+#define HWP_HIGHEST_PERF(x) (x & 0xff)
+#define HWP_GUARANTEED_PERF(x)((x & (0xff << 8)) >>8)
+#define HWP_MOSTEFFICIENT_PERF(x) ((x & (0xff << 16)) >>16)
+#define HWP_LOWEST_PERF(x)((x & (0xff << 24)) >>24)
+
+/* IA32_HWP_REQUEST */
+#define HWP_MIN_PERF(x) (x & 0xff)
+#define HWP_MAX_PERF(x) ((x & 0xff) << 8)
+#define HWP_DESIRED_PERF(x) ((x & 0xff) << 16)
+#define HWP_ENERGY_PERF_PREFERENCE(x) ((x & 0xff) << 24)
+#define HWP_ACTIVITY_WINDOW(x)((x & 0xff3) << 32)
+#define HWP_PACKAGE_CONTROL(x)((x & 0x1) << 42)
+
+/* IA32_HWP_STATUS */
+#define HWP_GUARANTEED_CHANGE(x) (x & 0x1)
+#define HWP_EXCURSION_TO_MINIMUM(x) (x & 0x4)
+
+/* IA32_HWP_INTERRUPT */
+#define HWP_CHANGE_TO_GUARANTEED_INT(x) (x & 0x1)
+#define HWP_EXCURSION_TO_MINIMUM_INT(x) (x & 0x2)
+
+ #define MSR_CORE_PERF_LIMIT_REASONS 0x0690
+ #define MSR_GFX_PERF_LIMIT_REASONS0x06B0
+ #define MSR_RING_PERF_LIMIT_REASONS 0x06B1
+
#define MSR_AMD64_MC0_MASK0xc0010044
#define MSR_IA32_MCx_CTL(x) (MSR_IA32_MC0_CTL + 4*(x))
pgpY46fUiKKcn.pgp
Description: OpenPGP digital signature
Re: [PATCH] kernel: removed unnecessary initialization of static variable
Gangadhar,
On Sun, Dec 21, 2014 at 09:09:05AM +0530, Gangadhar Vukkesala wrote:
> Removed unnecessary initialization of static variable "zero" to 0
> in pid_namespace.c as default value of static variable is 0.
> This issue was found when running checkpatch.pl script on pid_namespace.c.
>
> Signed-off-by: Gangadhar Vukkesala
> ---
> kernel/pid_namespace.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
> index a65ba13..f21eb3f 100644
> --- a/kernel/pid_namespace.c
> +++ b/kernel/pid_namespace.c
> @@ -290,7 +290,7 @@ static int pid_ns_ctl_handler(struct ctl_table *table,
> int write,
> }
>
> extern int pid_max;
> -static int zero = 0;
> +static int zero;
> static struct ctl_table pid_ns_ctl_table[] = {
> {
> .procname = "ns_last_pid",
> --
> Gangadhar Vukkesala
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Looks good.
Reviewed-by: Jeremiah Mahler
--
- Jeremiah Mahler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: comedi: fix spacing issues in ni_stc.h
Sage,
On Sat, Dec 20, 2014 at 09:01:54PM -0500, Sage Vaillancourt wrote:
> Patch to the ni_stc.h file that removes spaces before tabs, and adds blank
> lines
> after declarations.
> Signed-off-by: Sage Vaillancourt
Format your log message so it is no more than 80 characters wide (I like
72) and remove the gratuitous spacing on the second line.
Put a blank line between your log message and your Signed-off-by:
This patch is doing two things: adding blank lines and fixing
spaces/tabs in a line. Break it up in to two patches.
> ---
> drivers/staging/comedi/drivers/ni_stc.h | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/comedi/drivers/ni_stc.h
> b/drivers/staging/comedi/drivers/ni_stc.h
> index bd69c3f..3b8b3c5 100644
> --- a/drivers/staging/comedi/drivers/ni_stc.h
> +++ b/drivers/staging/comedi/drivers/ni_stc.h
> @@ -166,7 +166,7 @@ enum Interrupt_B_Ack_Bits {
> #define AI_SCAN_IN_PROG_Pulse_bit4
> #define AI_EXTMUX_CLK_Pulse _bit3
> #define AI_LOCALMUX_CLK_Pulse_bit2
> -#define AI_SC_TC_Pulse _bit1
> +#define AI_SC_TC_Pulse _bit1
> #define AI_CONVERT_Pulse _bit0
>
> #define AO_Command_1_Register9
> @@ -326,6 +326,7 @@ static inline unsigned RTSI_Output_Bit(unsigned channel,
> int is_mseries)
> {
> unsigned max_channel;
> unsigned base_bit_shift;
> +
> if (is_mseries) {
> base_bit_shift = 8;
> max_channel = 7;
> @@ -642,7 +643,7 @@ static unsigned AO_UPDATE_Output_Select(enum
> ao_update_output_selection
> #define G_Load_Source_Select _bit7
> #define G_Reload_Source_Switching_bit15
> #define G_Loading_On_Gate_bit14
> -#define G_Gate_Polarity _bit13
> +#define G_Gate_Polarity _bit13
>
> #define G_Counting_Once(a) (((a)&0x03)<<10)
> #define G_Stop_Mode(a) (((a)&0x03)<<5)
> @@ -1142,6 +1143,7 @@ static inline unsigned MSeries_AI_Config_Bank_Bits(enum
> ni_reg_type reg_type,
> unsigned channel)
> {
> unsigned bits = channel & 0x30;
> +
> if (reg_type == ni_reg_622x) {
> if (channel & 0x40)
> bits |= 0x400;
> @@ -1191,6 +1193,7 @@ enum MSeries_PLL_Control_Bits {
> static inline unsigned MSeries_PLL_Divisor_Bits(unsigned divisor)
> {
> static const unsigned max_divisor = 0x10;
> +
> if (divisor < 1 || divisor > max_divisor) {
> pr_err("%s: bug, invalid divisor=%i\n", __func__, divisor);
> return 0;
> @@ -1201,6 +1204,7 @@ static inline unsigned
> MSeries_PLL_Divisor_Bits(unsigned divisor)
> static inline unsigned MSeries_PLL_Multiplier_Bits(unsigned multiplier)
> {
> static const unsigned max_multiplier = 0x100;
> +
> if (multiplier < 1 || multiplier > max_multiplier) {
> pr_err("%s: bug, invalid multiplier=%i\n", __func__,
> multiplier);
> --
> 2.2.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/
--
- Jeremiah Mahler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.19-rc1 - merge window closed
Hi Linus, On Sat, 2014-12-20 at 17:43 -0800, Linus Torvalds wrote: > So it's been a day less than two weeks, and the merge window is closed. > > Considering how much came in fairly late, I find it hard to care about > anybody who had decided to cut it even closer than some people already > did. That said, maybe there aren't any real stragglers - and judging > by the size of rc1, there really can't have been much. Not only do I > think there are more commits than there were in linux-next, this is > one of the bigger rc1's (at least by commits) historically. We've had > bigger ones (3.10 and 3.15 both had large merge windows leading up to > them), but this was definitely not a small merge window. > > Anyway, we've got changes all over the place, including a new > architecture (nios2). My "short mergelog" is appended, and as usual I > want to point out that that credits the people sending me the changes, > which is generally not necessarily at all the same thing as the people > actually writing the code, even if there is obviously overlap. > > In the "big picture", this looks like a fairly normal release. About > two thirds driver updates, with about half of the rest being > architecture updates (and no, the new nios2 patches are not at all > dominant, it's about half ARM, with the new nios2 support being less > than 10% of the arch updates by lines overall). The remaining one > sixth is "misc": networking, header updates, documentation, > filesystems, tooling, and core kernel (in pretty much that order). > > Obviously, with the holidays coming up, I'd expect that the next few > weeks are pretty quiet, but we'll see. I do hope that people will have > time to test this all in between all the eggnog, > > Linus > Just hit the following build failure with CONFIG_AUDIT=y: arch/x86/ia32/audit.c: In function ‘ia32_classify_syscall’: arch/x86/ia32/audit.c:38:7: error: ‘__NR_execveat’ undeclared (first use in this function) arch/x86/ia32/audit.c:38:7: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [arch/x86/ia32/audit.o] Error 1 make[1]: *** [arch/x86/ia32] Error 2 make: *** [arch/x86] Error 2 make: *** Waiting for unfinished jobs Looks related to David's (CC'ed) recent execveat changes in commit 27d6ec7ad Config attached. --nab # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.19.0-rc1 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_FHANDLE is not set # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # CONFIG_AUDITSYSCALL is not set # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_G
Re: [PATCH] Staging: clocking-wizard: Added a blank line after declaration
Hi Mohammad,
On Sun, 2014-12-21 at 08:03AM +0530, Mohammad Jamal wrote:
> Fix the coding style issue by adding blank line after declaration
>
> Signed-off-by: Mohammad Jamal
> ---
> .../clocking-wizard/clk-xlnx-clock-wizard.c|1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> index 471d087..ea8d561 100644
> --- a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> +++ b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> @@ -239,6 +239,7 @@ static int clk_wzrd_probe(struct platform_device *pdev)
> /* register div per output */
> for (i = WZRD_NUM_OUTPUTS - 1; i >= 0 ; i--) {
> const char *clkout_name;
> +
> if (of_property_read_string_index(np, "clock-output-names", i,
> &clkout_name)) {
> dev_err(&pdev->dev,
I think the same patch had already been sent to the list by somebody
else. Not sure whether Greg picked it up yet.
Either way, feel free to add my
Acked-by: Soren Brinkmann
Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: vt6655: fix sparse warning: argument type
Fixes following warning generated by sparse: drivers/staging/vt6655/baseband.c:2180:45: warning: incorrect type in argument 1 (different address spaces) drivers/staging/vt6655/baseband.c:2180:45:expected struct vnt_private *priv drivers/staging/vt6655/baseband.c:2180:45:got void [noderef] *dwIoBase Compile tested on next-20141219. Signed-off-by: Eddie Kovsky --- drivers/staging/vt6655/baseband.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6655/baseband.c b/drivers/staging/vt6655/baseband.c index 86c72ba0a0cd..f8c5fc371c4c 100644 --- a/drivers/staging/vt6655/baseband.c +++ b/drivers/staging/vt6655/baseband.c @@ -2177,7 +2177,7 @@ bool BBbVT3253Init(struct vnt_private *priv) /* Init ANT B select,RX Config CR10 = 0x28->0x2A, 0x2A->0x28(VC1/VC2 define, make the ANT_A, ANT_B inverted) */ /*bResult &= BBbWriteEmbedded(dwIoBase,0x0a,0x28);*/ /* Select VC1/VC2, CR215 = 0x02->0x06 */ - bResult &= BBbWriteEmbedded(dwIoBase, 0xd7, 0x06); + bResult &= BBbWriteEmbedded(priv, 0xd7, 0x06); /* }} */ for (ii = 0; ii < CB_VT3253B0_AGC; ii++) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.19-rc1 - merge window closed
On Sat, Dec 20, 2014 at 05:43:22PM -0800, Linus Torvalds wrote: > So it's been a day less than two weeks, and the merge window is closed. > > Considering how much came in fairly late, I find it hard to care about > anybody who had decided to cut it even closer than some people already > did. That said, maybe there aren't any real stragglers - and judging > by the size of rc1, there really can't have been much. Not only do I > think there are more commits than there were in linux-next, this is > one of the bigger rc1's (at least by commits) historically. We've had > bigger ones (3.10 and 3.15 both had large merge windows leading up to > them), but this was definitely not a small merge window. > > Anyway, we've got changes all over the place, including a new > architecture (nios2). My "short mergelog" is appended, and as usual I > want to point out that that credits the people sending me the changes, > which is generally not necessarily at all the same thing as the people > actually writing the code, even if there is obviously overlap. > > In the "big picture", this looks like a fairly normal release. About > two thirds driver updates, with about half of the rest being > architecture updates (and no, the new nios2 patches are not at all > dominant, it's about half ARM, with the new nios2 support being less > than 10% of the arch updates by lines overall). The remaining one > sixth is "misc": networking, header updates, documentation, > filesystems, tooling, and core kernel (in pretty much that order). > > Obviously, with the holidays coming up, I'd expect that the next few > weeks are pretty quiet, but we'll see. I do hope that people will have > time to test this all in between all the eggnog, > There are at least the never-resting auto-testers, which for mine report: Build tests: total: 133 pass: 133 fail: 0 Qemu tests: total: 30 pass: 30 fail: 0 Details at http://server.roeck-us.net:8010/builders. This is an absolute first; since I started testing, we never had an -rc1 with no build or qemu failures. Excellent job everyone! Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] misc: cxl: sysfs.c: Remove unused function
> Remove the function mmio_size_show() that is not used anywhere.
Did you compile check this patch?
drivers/misc/cxl/sysfs.c:291:74: error: ‘mmio_size_show’ undeclared here (not
in a function)
It's used here:
static struct device_attribute afu_attrs[] = {
__ATTR_RO(mmio_size),
> This was partially found by using a static code analysis program called
> cppcheck.
Thanks for letting me know which tool to avoid :-)
Mikey
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/misc/cxl/sysfs.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/misc/cxl/sysfs.c b/drivers/misc/cxl/sysfs.c
> index ce7ec06..0431ec3 100644
> --- a/drivers/misc/cxl/sysfs.c
> +++ b/drivers/misc/cxl/sysfs.c
> @@ -102,17 +102,6 @@ static struct device_attribute afu_master_attrs[] = {
>
> /* AFU attributes
> **/
>
> -static ssize_t mmio_size_show(struct device *device,
> - struct device_attribute *attr,
> - char *buf)
> -{
> - struct cxl_afu *afu = to_cxl_afu(device);
> -
> - if (afu->pp_size)
> - return scnprintf(buf, PAGE_SIZE, "%llu\n", afu->pp_size);
> - return scnprintf(buf, PAGE_SIZE, "%llu\n", afu->adapter->ps_size);
> -}
> -
> static ssize_t reset_store_afu(struct device *device,
> struct device_attribute *attr,
> const char *buf, size_t count)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sat, Dec 20, 2014 at 01:16:29PM -0800, Linus Torvalds wrote:
> On Sat, Dec 20, 2014 at 10:25 AM, Linus Torvalds
> wrote:
> >
> > How/where is the HPET overflow case handled? I don't know the code enough.
>
> Hmm, ok, I've re-acquainted myself with it. And I have to admit that I
> can't see anything wrong. The whole "update_wall_clock" and the shadow
> timekeeping state is confusing as hell, but seems fine. We'd have to
> avoid update_wall_clock for a *long* time for overflows to occur.
>
> And the overflow in 32 bits isn't that special, since the only thing
> that really matters is the overflow of "cycle_now - tkr->cycle_last"
> within the mask.
>
> So I'm not seeing anything even halfway suspicious.
One long shot is a bug in rcu_barrier() that I introduced in v3.18-rc1.
This is a low-probability race that can cause rcu_barrier() and friends
to return too soon, which can of course result in arbitrary misbehavior.
Please see below for a fix which looks good thus far in reasonably
intense rcutorture testing.
Might be what Dave and Sasha are seeing. Or not.
Thanx, Paul
rcu: Fix rcu_barrier() race that could result in too-short wait
The rcu_barrier() no-callbacks check for no-CBs CPUs has race conditions.
It checks a given CPU's lists of callbacks, and if all three no-CBs lists
are empty, ignores that CPU. However, these three lists could potentially
be empty even when callbacks are present if the check executed just as
the callbacks were being moved from one list to another. It turns out
that recent versions of rcutorture can spot this race.
This commit plugs this hole by consolidating the per-list counts of
no-CBs callbacks into a single count, which is incremented before
the corresponding callback is posted and after it is invoked. Then
rcu_barrier() checks this single count to reliably determine whether
the corresponding CPU has no-CBs callbacks.
Signed-off-by: Paul E. McKenney
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 7680fc275036..658b691dc32b 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3318,6 +3318,7 @@ static void _rcu_barrier(struct rcu_state *rsp)
} else {
_rcu_barrier_trace(rsp, "OnlineNoCB", cpu,
rsp->n_barrier_done);
+ smp_mb__before_atomic();
atomic_inc(&rsp->barrier_cpu_count);
__call_rcu(&rdp->barrier_head,
rcu_barrier_callback, rsp, cpu, 0);
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index 8e7b1843896e..cb5908672f11 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -340,14 +340,10 @@ struct rcu_data {
#ifdef CONFIG_RCU_NOCB_CPU
struct rcu_head *nocb_head; /* CBs waiting for kthread. */
struct rcu_head **nocb_tail;
- atomic_long_t nocb_q_count; /* # CBs waiting for kthread */
- atomic_long_t nocb_q_count_lazy; /* (approximate). */
+ atomic_long_t nocb_q_count; /* # CBs waiting for nocb */
+ atomic_long_t nocb_q_count_lazy; /* invocation (all stages). */
struct rcu_head *nocb_follower_head; /* CBs ready to invoke. */
struct rcu_head **nocb_follower_tail;
- atomic_long_t nocb_follower_count; /* # CBs ready to invoke. */
- atomic_long_t nocb_follower_count_lazy; /* (approximate). */
- int nocb_p_count; /* # CBs being invoked by kthread */
- int nocb_p_count_lazy; /* (approximate). */
wait_queue_head_t nocb_wq; /* For nocb kthreads to sleep on. */
struct task_struct *nocb_kthread;
int nocb_defer_wakeup; /* Defer wakeup of nocb_kthread. */
@@ -356,8 +352,6 @@ struct rcu_data {
struct rcu_head *nocb_gp_head cacheline_internodealigned_in_smp;
/* CBs waiting for GP. */
struct rcu_head **nocb_gp_tail;
- long nocb_gp_count;
- long nocb_gp_count_lazy;
bool nocb_leader_sleep; /* Is the nocb leader thread asleep? */
struct rcu_data *nocb_next_follower;
/* Next follower in wakeup chain. */
@@ -622,24 +616,15 @@ static void rcu_dynticks_task_exit(void);
#endif /* #ifndef RCU_TREE_NONCORE */
#ifdef CONFIG_RCU_TRACE
-#ifdef CONFIG_RCU_NOCB_CPU
-/* Sum up queue lengths for tracing. */
+/* Read out queue lengths for tracing. */
static inline void rcu_nocb_q_lengths(struct rcu_data *rdp, long *ql, long
*qll)
{
- *ql = atomic_long_read(&rdp->nocb_q_count) +
- rdp->nocb_p_count +
- atomic_long_read(&rdp->nocb_follower_count) +
- rdp->nocb_p_count + rdp->nocb_gp_count;
- *qll = atomic_long_read(&rdp->nocb_q_count_lazy) +
- rdp->no
[PATCH] kernel: removed unnecessary initialization of static variable
Removed unnecessary initialization of static variable "zero" to 0
in pid_namespace.c as default value of static variable is 0.
This issue was found when running checkpatch.pl script on pid_namespace.c.
Signed-off-by: Gangadhar Vukkesala
---
kernel/pid_namespace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
index a65ba13..f21eb3f 100644
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -290,7 +290,7 @@ static int pid_ns_ctl_handler(struct ctl_table *table, int
write,
}
extern int pid_max;
-static int zero = 0;
+static int zero;
static struct ctl_table pid_ns_ctl_table[] = {
{
.procname = "ns_last_pid",
--
Gangadhar Vukkesala
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Cleaning up the KVM clock
I'm looking at the vdso timing code, and I'm puzzled by the pvclock code. My motivation is comprehensibility, performance, and correctness. # for i in `seq 10`; do ./timing_test_64 10 vclock_gettime 0; done 1000 loops in 0.69138s = 69.14 nsec / loop 1000 loops in 0.63614s = 63.61 nsec / loop 1000 loops in 0.63213s = 63.21 nsec / loop 1000 loops in 0.63087s = 63.09 nsec / loop 1000 loops in 0.63079s = 63.08 nsec / loop 1000 loops in 0.63096s = 63.10 nsec / loop 1000 loops in 0.63096s = 63.10 nsec / loop 1000 loops in 0.63062s = 63.06 nsec / loop 1000 loops in 0.63100s = 63.10 nsec / loop 1000 loops in 0.63112s = 63.11 nsec / loop bash-4.3# echo tsc >/sys/devices/system/clocksource/clocksource0/current_clocksource [ 45.957524] Switched to clocksource tsc bash-4.3# for i in `seq 10`; do ./timing_test_64 10 vclock_gettime 0; done1000 loops in 0.33583s = 33.58 nsec / loop 1000 loops in 0.28530s = 28.53 nsec / loop 1000 loops in 0.28904s = 28.90 nsec / loop 1000 loops in 0.29001s = 29.00 nsec / loop 1000 loops in 0.28775s = 28.78 nsec / loop 1000 loops in 0.30102s = 30.10 nsec / loop 1000 loops in 0.28006s = 28.01 nsec / loop 1000 loops in 0.28584s = 28.58 nsec / loop 1000 loops in 0.28175s = 28.17 nsec / loop 1000 loops in 0.28724s = 28.72 nsec / loop The current code is rather slow, especially compared to the tsc variant. The algorithm used by the pvclock vgetsns implementation is, approximately: cpu = getcpu; pvti = pointer to the relevant paravirt data version = pvti->version; rdtsc_barrier(); tsc = rdtsc() delta = (tsc - x) * y >> z; cycles = delta + w; flags = pvti->flags; rdtsc_barrier(); <-- totally unnecessary cpu1 = getcpu; if (cpu != cpu1 || the we missed the seqlock) retry; if (!stable) bail; After that, the main vclock_gettime code applies the kernel's regular time adjustments. First, is there any guarantee that, if pvti is marked as stable, that the pvti data is consistent across cpus? If so (which would be really nice), then we could always use vcpu 0's pvti, which would be a really nice cleanup. If not, then the current algorithm is buggy. There is no guarantee that the tsc stamp we get matches the cpu whose pvti we looked at. We could fix that using rdtscp. I think it's also rather strange that the return value is "cycles" instead of nanoseconds. If the guest is using pvclock *and* ntp, isn't something very wrong? Can the algorithm just be: tsc, cpu = rdtscp; pvti = pvti for cpu read the scale, offset, etc; if (!stable) bail; barrier(); read pvti->tsc_timestamp; if (tsc < pvti->tsc_timestamp) retry; if (the versions are unhappy) retry; return the computed nanosecond count; I think this is likely to be at least as correct as the current algorithm, if not more so, and it correctly handles the case where we migrate to a different vcpu in the middle. (I also think that, with this algorithm, the version check should also be unnecessary, since if we race with a host update, we'll fail the tsc < pvti->tsc_timestamp check.) It would be even nicer, though, if we could do much the same thing but without worrying about which vcpu we're on. Thoughts? Am I missing some considerations here? --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] media: fix au0828_analog_register() to not free au0828_dev
au0828_analog_register() frees au0828_dev when it fails to
locate isoc endpoint. au0828_usb_probe() continues with dvb
and rc probe and registration assuming dev is still valid.
When au0828_analog_register() fails to locate isoc endpoint,
it should return without free'ing au0828_dev. Otherwise, the
probe will fail as dev is null when au0828_dvb_register() is
called.
Signed-off-by: Shuah Khan
---
Resending as the first one had malformed changelog
drivers/media/usb/au0828/au0828-video.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/usb/au0828/au0828-video.c
b/drivers/media/usb/au0828/au0828-video.c
index 3bdf132..94b65b8 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -1713,7 +1713,6 @@ int au0828_analog_register(struct au0828_dev *dev,
}
if (!(dev->isoc_in_endpointaddr)) {
pr_info("Could not locate isoc endpoint\n");
- kfree(dev);
return -ENODEV;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rtl8192e: fixed a space coding style issue
Fixed a space coding style issue in 3-dimensional array initialization
which was found when running checkpatch.pl script on rtl819x_HTProc.c.
Signed-off-by: Gangadhar Vukkesala
---
drivers/staging/rtl8192e/rtl819x_HTProc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c
b/drivers/staging/rtl8192e/rtl819x_HTProc.c
index c7f4508..1ea426b 100644
--- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
@@ -34,13 +34,13 @@ u16 MCS_DATA_RATE[2][2][77] = {
468, 520, 0, 78, 104, 130, 117, 156, 195, 104, 130, 130, 156, 182,
182, 208, 156, 195, 195, 234, 273, 273, 312, 130, 156, 181, 156,
181, 208, 234, 208, 234, 260, 260, 286, 195, 234, 273, 234, 273,
-312, 351, 312, 351, 390, 390, 429} ,
+312, 351, 312, 351, 390, 390, 429},
{14, 29, 43, 58, 87, 116, 130, 144, 29, 58, 87, 116, 173, 231, 260, 289,
43, 87, 130, 173, 260, 347, 390, 433, 58, 116, 173, 231, 347, 462, 520,
578, 0, 87, 116, 144, 130, 173, 217, 116, 144, 144, 173, 202, 202, 231,
173, 217, 217, 260, 303, 303, 347, 144, 173, 202, 173, 202, 231, 260,
231, 260, 289, 289, 318, 217, 260, 303, 260, 303, 347, 390, 347, 390,
-433, 433, 477} } ,
+433, 433, 477} },
{{27, 54, 81, 108, 162, 216, 243, 270, 54, 108, 162, 216, 324, 432, 486,
540, 81, 162, 243, 324, 486, 648, 729, 810, 108, 216, 324, 432, 648,
864, 972, 1080, 12, 162, 216, 270, 243, 324, 405, 216, 270, 270, 324,
--
Gangadhar Vukkesala
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging : gdm724x: Remove space before , in function arguments
This patch solves space prohibited before , warning in gdm_mux.c
Signed-off-by: Mohammad Jamal
---
drivers/staging/gdm724x/gdm_mux.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gdm724x/gdm_mux.c
b/drivers/staging/gdm724x/gdm_mux.c
index b5b063a..d1ab996 100644
--- a/drivers/staging/gdm724x/gdm_mux.c
+++ b/drivers/staging/gdm724x/gdm_mux.c
@@ -220,7 +220,7 @@ static int up_to_host(struct mux_rx *r)
static void do_rx(struct work_struct *work)
{
struct mux_dev *mux_dev =
- container_of(work, struct mux_dev , work_rx.work);
+ container_of(work, struct mux_dev, work_rx.work);
struct mux_rx *r;
struct rx_cxt *rx = (struct rx_cxt *)&mux_dev->rx;
unsigned long flags;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpu: drm: nouveau: core: subdev: clock: base.c: Remove unused function
- Original Message -
> From: "Rickard Strandqvist"
> To: "David Airlie" , "Ben Skeggs"
> Cc: "Rickard Strandqvist" ,
> "Alexandre Courbot" , "Ilia
> Mirkin" , dri-de...@lists.freedesktop.org,
> linux-kernel@vger.kernel.org
> Sent: Sunday, 21 December, 2014 2:54:16 AM
> Subject: [PATCH] gpu: drm: nouveau: core: subdev: clock: base.c: Remove
> unused function
>
> Remove the function nouveau_clock_astate() that is not used anywhere.
No, don't remove this. It's only not used because noone got around to
finishing load-based reclocking yet.
NVIDIA has an implementation for the GK20A in the works that uses it.
Ben.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/drm/nouveau/core/include/subdev/clock.h |1 -
> drivers/gpu/drm/nouveau/core/subdev/clock/base.c| 10 --
> 2 files changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/clock.h
> b/drivers/gpu/drm/nouveau/core/include/subdev/clock.h
> index 36ed035..8577945 100644
> --- a/drivers/gpu/drm/nouveau/core/include/subdev/clock.h
> +++ b/drivers/gpu/drm/nouveau/core/include/subdev/clock.h
> @@ -159,7 +159,6 @@ int nva3_clock_pll_calc(struct nouveau_clock *, struct
> nvbios_pll *,
> int clk, struct nouveau_pll_vals *);
>
> int nouveau_clock_ustate(struct nouveau_clock *, int req, int pwr);
> -int nouveau_clock_astate(struct nouveau_clock *, int req, int rel);
> int nouveau_clock_dstate(struct nouveau_clock *, int req, int rel);
> int nouveau_clock_tstate(struct nouveau_clock *, int req, int rel);
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
> index e51b72d..b2c852a 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
> @@ -430,16 +430,6 @@ nouveau_clock_ustate(struct nouveau_clock *clk, int req,
> int pwr)
> }
>
> int
> -nouveau_clock_astate(struct nouveau_clock *clk, int req, int rel)
> -{
> - if (!rel) clk->astate = req;
> - if ( rel) clk->astate += rel;
> - clk->astate = min(clk->astate, clk->state_nr - 1);
> - clk->astate = max(clk->astate, 0);
> - return nouveau_pstate_calc(clk, true);
> -}
> -
> -int
> nouveau_clock_tstate(struct nouveau_clock *clk, int req, int rel)
> {
> if (!rel) clk->tstate = req;
> --
> 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] Staging: clocking-wizard: Added a blank line after declaration
Fix the coding style issue by adding blank line after declaration
Signed-off-by: Mohammad Jamal
---
.../clocking-wizard/clk-xlnx-clock-wizard.c|1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
index 471d087..ea8d561 100644
--- a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
+++ b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
@@ -239,6 +239,7 @@ static int clk_wzrd_probe(struct platform_device *pdev)
/* register div per output */
for (i = WZRD_NUM_OUTPUTS - 1; i >= 0 ; i--) {
const char *clkout_name;
+
if (of_property_read_string_index(np, "clock-output-names", i,
&clkout_name)) {
dev_err(&pdev->dev,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: comedi: fix spacing issues in ni_stc.h
Patch to the ni_stc.h file that removes spaces before tabs, and adds blank lines
after declarations.
Signed-off-by: Sage Vaillancourt
---
drivers/staging/comedi/drivers/ni_stc.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_stc.h
b/drivers/staging/comedi/drivers/ni_stc.h
index bd69c3f..3b8b3c5 100644
--- a/drivers/staging/comedi/drivers/ni_stc.h
+++ b/drivers/staging/comedi/drivers/ni_stc.h
@@ -166,7 +166,7 @@ enum Interrupt_B_Ack_Bits {
#define AI_SCAN_IN_PROG_Pulse _bit4
#define AI_EXTMUX_CLK_Pulse_bit3
#define AI_LOCALMUX_CLK_Pulse _bit2
-#define AI_SC_TC_Pulse _bit1
+#define AI_SC_TC_Pulse _bit1
#define AI_CONVERT_Pulse _bit0
#define AO_Command_1_Register 9
@@ -326,6 +326,7 @@ static inline unsigned RTSI_Output_Bit(unsigned channel,
int is_mseries)
{
unsigned max_channel;
unsigned base_bit_shift;
+
if (is_mseries) {
base_bit_shift = 8;
max_channel = 7;
@@ -642,7 +643,7 @@ static unsigned AO_UPDATE_Output_Select(enum
ao_update_output_selection
#define G_Load_Source_Select _bit7
#define G_Reload_Source_Switching _bit15
#define G_Loading_On_Gate _bit14
-#define G_Gate_Polarity_bit13
+#define G_Gate_Polarity_bit13
#define G_Counting_Once(a) (((a)&0x03)<<10)
#define G_Stop_Mode(a) (((a)&0x03)<<5)
@@ -1142,6 +1143,7 @@ static inline unsigned MSeries_AI_Config_Bank_Bits(enum
ni_reg_type reg_type,
unsigned channel)
{
unsigned bits = channel & 0x30;
+
if (reg_type == ni_reg_622x) {
if (channel & 0x40)
bits |= 0x400;
@@ -1191,6 +1193,7 @@ enum MSeries_PLL_Control_Bits {
static inline unsigned MSeries_PLL_Divisor_Bits(unsigned divisor)
{
static const unsigned max_divisor = 0x10;
+
if (divisor < 1 || divisor > max_divisor) {
pr_err("%s: bug, invalid divisor=%i\n", __func__, divisor);
return 0;
@@ -1201,6 +1204,7 @@ static inline unsigned MSeries_PLL_Divisor_Bits(unsigned
divisor)
static inline unsigned MSeries_PLL_Multiplier_Bits(unsigned multiplier)
{
static const unsigned max_multiplier = 0x100;
+
if (multiplier < 1 || multiplier > max_multiplier) {
pr_err("%s: bug, invalid multiplier=%i\n", __func__,
multiplier);
--
2.2.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] media: pci: cx18: cx18-alsa-mixer.c: Remove some unused functions
On December 20, 2014 8:17:05 PM EST, Rickard Strandqvist
wrote:
>2014-12-21 1:06 GMT+01:00 Andy Walls :
>> On December 20, 2014 5:35:17 PM EST, Rickard Strandqvist
> wrote:
>>>Removes some functions that are not used anywhere:
>>>snd_cx18_mixer_tv_vol_get() snd_cx18_mixer_tv_vol_info()
>>>snd_cx18_mixer_tv_vol_put()
>>>
>>>This was partially found by using a static code analysis program
>called
>>>cppcheck.
>>>
>>>Signed-off-by: Rickard Strandqvist
>>>
>>>---
>>>drivers/media/pci/cx18/cx18-alsa-mixer.c | 62
>>>--
>>> 1 file changed, 62 deletions(-)
>>>
>>>diff --git a/drivers/media/pci/cx18/cx18-alsa-mixer.c
>>>b/drivers/media/pci/cx18/cx18-alsa-mixer.c
>>>index 341bddc..e7b0a1f 100644
>>>--- a/drivers/media/pci/cx18/cx18-alsa-mixer.c
>>>+++ b/drivers/media/pci/cx18/cx18-alsa-mixer.c
>>>@@ -69,68 +69,6 @@ static inline int cx18_av_vol_to_dB(int v)
>>> return (v >> 9) - 119;
>>> }
>>>
>>>-static int snd_cx18_mixer_tv_vol_info(struct snd_kcontrol *kcontrol,
>>>-struct snd_ctl_elem_info *uinfo)
>>>-{
>>>- uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
>>>- uinfo->count = 1;
>>>- /* We're already translating values, just keep this control in
>dB */
>>>- uinfo->value.integer.min = -96;
>>>- uinfo->value.integer.max = 8;
>>>- uinfo->value.integer.step = 1;
>>>- return 0;
>>>-}
>>>-
>>>-static int snd_cx18_mixer_tv_vol_get(struct snd_kcontrol *kctl,
>>>- struct snd_ctl_elem_value *uctl)
>>>-{
>>>- struct snd_cx18_card *cxsc = snd_kcontrol_chip(kctl);
>>>- struct cx18 *cx = to_cx18(cxsc->v4l2_dev);
>>>- struct v4l2_control vctrl;
>>>- int ret;
>>>-
>>>- vctrl.id = V4L2_CID_AUDIO_VOLUME;
>>>- vctrl.value = dB_to_cx18_av_vol(uctl->value.integer.value[0]);
>>>-
>>>- snd_cx18_lock(cxsc);
>>>- ret = v4l2_subdev_call(cx->sd_av, core, g_ctrl, &vctrl);
>>>- snd_cx18_unlock(cxsc);
>>>-
>>>- if (!ret)
>>>- uctl->value.integer.value[0] =
>cx18_av_vol_to_dB(vctrl.value);
>>>- return ret;
>>>-}
>>>-
>>>-static int snd_cx18_mixer_tv_vol_put(struct snd_kcontrol *kctl,
>>>- struct snd_ctl_elem_value *uctl)
>>>-{
>>>- struct snd_cx18_card *cxsc = snd_kcontrol_chip(kctl);
>>>- struct cx18 *cx = to_cx18(cxsc->v4l2_dev);
>>>- struct v4l2_control vctrl;
>>>- int ret;
>>>-
>>>- vctrl.id = V4L2_CID_AUDIO_VOLUME;
>>>- vctrl.value = dB_to_cx18_av_vol(uctl->value.integer.value[0]);
>>>-
>>>- snd_cx18_lock(cxsc);
>>>-
>>>- /* Fetch current state */
>>>- ret = v4l2_subdev_call(cx->sd_av, core, g_ctrl, &vctrl);
>>>-
>>>- if (ret ||
>>>- (cx18_av_vol_to_dB(vctrl.value) !=
>uctl->value.integer.value[0]))
>>>{
>>>-
>>>- /* Set, if needed */
>>>- vctrl.value =
>dB_to_cx18_av_vol(uctl->value.integer.value[0]);
>>>- ret = v4l2_subdev_call(cx->sd_av, core, s_ctrl,
>&vctrl);
>>>- if (!ret)
>>>- ret = 1; /* Indicate control was changed w/o
>error */
>>>- }
>>>- snd_cx18_unlock(cxsc);
>>>-
>>>- return ret;
>>>-}
>>>-
>>>
>>>/* This is a bit of overkill, the slider is already in dB internally
>*/
>>>static DECLARE_TLV_DB_SCALE(snd_cx18_mixer_tv_vol_db_scale, -9600,
>100,
>>>0);
>>
>> Really? Did you try to compile the file after this patch?
>>
>>
>http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/pci/cx18/cx18-alsa-mixer.c#n143
>>
>> They are referenced later in the same file.
>>
>> This is only half a fix.
>>
>> You can either remove the cx18-alsa-mixer.* files and from the build
>system, or even better,you can hook-up and initialize these callbacks
>with alsa so alsa mixer controls show up for cx18. :)
>>
>
>
>
>Hi
>
>Ok sorry :-(
>
>Sure, I compile everything as allyesconfig, allmodconfig and
>allnoconfig.
>
>So snd_cx18_mixer_tv_volume_info is the same as
>snd_cx18_mixer_tv_vol_info then.
>
>Would gladly done something a little more concrete.
>But first I want to see if as I can go through all of the
>approximately 2000 functions that are not in use.
>
>
>Kind regards
>Rickard Strandqvist
Yes they are supposed to be the same. It is dead code with typographical
errors. So it is probably not even in the Makefile.
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 3.19-rc1 - merge window closed
So it's been a day less than two weeks, and the merge window is closed. Considering how much came in fairly late, I find it hard to care about anybody who had decided to cut it even closer than some people already did. That said, maybe there aren't any real stragglers - and judging by the size of rc1, there really can't have been much. Not only do I think there are more commits than there were in linux-next, this is one of the bigger rc1's (at least by commits) historically. We've had bigger ones (3.10 and 3.15 both had large merge windows leading up to them), but this was definitely not a small merge window. Anyway, we've got changes all over the place, including a new architecture (nios2). My "short mergelog" is appended, and as usual I want to point out that that credits the people sending me the changes, which is generally not necessarily at all the same thing as the people actually writing the code, even if there is obviously overlap. In the "big picture", this looks like a fairly normal release. About two thirds driver updates, with about half of the rest being architecture updates (and no, the new nios2 patches are not at all dominant, it's about half ARM, with the new nios2 support being less than 10% of the arch updates by lines overall). The remaining one sixth is "misc": networking, header updates, documentation, filesystems, tooling, and core kernel (in pretty much that order). Obviously, with the holidays coming up, I'd expect that the next few weeks are pretty quiet, but we'll see. I do hope that people will have time to test this all in between all the eggnog, Linus --- Al Viro (3): VFS changes vfs pile #2 vfs pile #3 Alex Williamson (1): VFIO updates Andrew Morton (3): first patchbomb second patchbomb misc patches Arnd Bergmann (13): ARM SoC non-critical bug fixes ARM SoC cleanup on mach-at91 ARM SoC cleanups ARM SoC platform changes ARM SoC driver updates ARM SoC DT updates ARM SoC/OMAP GPMC driver cleanup and move ARM SoC defconfig changes ARM64 SoC changes asm-generic asm/io.h rewrite ARM SoC fixes ARM SoC DT updates part 2 ARM SoC/iommu configuration update Artem Bityutskiy (1): UBI/UBIFS updates Benjamin LaHaise (1): aio updates Bjorn Helgaas (1): PCI changes Borislav Petkov (1): EDAC updates Brian Norris (1): MTD updates Bruce Fields (1): nfsd updates Bryan Wu (1): LED subsystem update Chris Mason (2): btrfs update more btrfs updates Chris Metcalf (1): arch/tile updates Chris Zankel (1): Xtensa fixes Christian Borntraeger (1): ACCESS_ONCE cleanup preparation Corey Minyard (1): IPMI driver updates Darren Hart (1): x86 platform driver update Dave Airlie (1): drm updates Dave Chinner (1): xfs update David Miller (6): networking updates sparc update IDE update another networking update sparc fix networking fixes David Teigland (1): dlm update David Vrabel (2): xen features and fixes additional xen update Dmitry Torokhov (1): input subsystem updates Eric Biederman (1): user namespace related fixes Geert Uytterhoeven (1): m68k updates Grant Likely (1): devicetree changes Greg KH (5): USB updates tty/serial driver updates driver core update char/misc driver updates staging driver updates Guenter Roeck (1): hwmon updates Herbert Xu (1): crypto update Ingo Molnar (17): locking tree changes RCU updates perf events update leftover perf fixes scheduler updates x86 asm updates x86 boot and percpu updates x86 build, cleanup and defconfig updates EFI updates x86 platform changes x86 mm tree changes x86 RAS update x86 vdso updates x86 microcode loading updates x86 fixes perf fixes and cleanups x86 fix Jaegeuk Kim (1): f2fs updates James Bottomley (2): SCSI updates SCSI update James Morris (2): security layer updates security subsystem fixes Jan Kara (2): quota updates isofs and reiserfs fixes Jassi Brar (1): mailbox framework updates Jens Axboe (3): block driver core update block layer driver updates core block fix Jesper Nilsson (1): arch/chris updates Jiri Kosina (2): trivial tree update HID updates Joerg Roedel (1): IOMMU updates Jonathan Corbet (1): documentation update Lee Jones (2): MFD updates backlight updates Ley Foon Tan (2): Altera Nios II processor support arch/nios2 fixes Linus Walleij (1): pin control changes Mark Brown (3): regmap updates regulator updates spi updates Martin Schwidefsky (1): s390 updates Mauro Carvalho Chehab (3): media updates edac updates second set of media updates Michael Ellerman (2): powerpc updates second batch of powerpc updates Michael S Tsirkin (1): virtio fixes Michael Tsirkin (1): virtio updates Michal Marek (2): kbuild updates misc kbuild changes Michal Simek (1): Microblaze fix Mike Snitzer (1): device mapper updates Mike Turquette (1): clk framewor
Re: [PATCH] media: pci: cx18: cx18-alsa-mixer.c: Remove some unused functions
2014-12-21 1:06 GMT+01:00 Andy Walls :
> On December 20, 2014 5:35:17 PM EST, Rickard Strandqvist
> wrote:
>>Removes some functions that are not used anywhere:
>>snd_cx18_mixer_tv_vol_get() snd_cx18_mixer_tv_vol_info()
>>snd_cx18_mixer_tv_vol_put()
>>
>>This was partially found by using a static code analysis program called
>>cppcheck.
>>
>>Signed-off-by: Rickard Strandqvist
>>
>>---
>>drivers/media/pci/cx18/cx18-alsa-mixer.c | 62
>>--
>> 1 file changed, 62 deletions(-)
>>
>>diff --git a/drivers/media/pci/cx18/cx18-alsa-mixer.c
>>b/drivers/media/pci/cx18/cx18-alsa-mixer.c
>>index 341bddc..e7b0a1f 100644
>>--- a/drivers/media/pci/cx18/cx18-alsa-mixer.c
>>+++ b/drivers/media/pci/cx18/cx18-alsa-mixer.c
>>@@ -69,68 +69,6 @@ static inline int cx18_av_vol_to_dB(int v)
>> return (v >> 9) - 119;
>> }
>>
>>-static int snd_cx18_mixer_tv_vol_info(struct snd_kcontrol *kcontrol,
>>-struct snd_ctl_elem_info *uinfo)
>>-{
>>- uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
>>- uinfo->count = 1;
>>- /* We're already translating values, just keep this control in dB */
>>- uinfo->value.integer.min = -96;
>>- uinfo->value.integer.max = 8;
>>- uinfo->value.integer.step = 1;
>>- return 0;
>>-}
>>-
>>-static int snd_cx18_mixer_tv_vol_get(struct snd_kcontrol *kctl,
>>- struct snd_ctl_elem_value *uctl)
>>-{
>>- struct snd_cx18_card *cxsc = snd_kcontrol_chip(kctl);
>>- struct cx18 *cx = to_cx18(cxsc->v4l2_dev);
>>- struct v4l2_control vctrl;
>>- int ret;
>>-
>>- vctrl.id = V4L2_CID_AUDIO_VOLUME;
>>- vctrl.value = dB_to_cx18_av_vol(uctl->value.integer.value[0]);
>>-
>>- snd_cx18_lock(cxsc);
>>- ret = v4l2_subdev_call(cx->sd_av, core, g_ctrl, &vctrl);
>>- snd_cx18_unlock(cxsc);
>>-
>>- if (!ret)
>>- uctl->value.integer.value[0] = cx18_av_vol_to_dB(vctrl.value);
>>- return ret;
>>-}
>>-
>>-static int snd_cx18_mixer_tv_vol_put(struct snd_kcontrol *kctl,
>>- struct snd_ctl_elem_value *uctl)
>>-{
>>- struct snd_cx18_card *cxsc = snd_kcontrol_chip(kctl);
>>- struct cx18 *cx = to_cx18(cxsc->v4l2_dev);
>>- struct v4l2_control vctrl;
>>- int ret;
>>-
>>- vctrl.id = V4L2_CID_AUDIO_VOLUME;
>>- vctrl.value = dB_to_cx18_av_vol(uctl->value.integer.value[0]);
>>-
>>- snd_cx18_lock(cxsc);
>>-
>>- /* Fetch current state */
>>- ret = v4l2_subdev_call(cx->sd_av, core, g_ctrl, &vctrl);
>>-
>>- if (ret ||
>>- (cx18_av_vol_to_dB(vctrl.value) != uctl->value.integer.value[0]))
>>{
>>-
>>- /* Set, if needed */
>>- vctrl.value = dB_to_cx18_av_vol(uctl->value.integer.value[0]);
>>- ret = v4l2_subdev_call(cx->sd_av, core, s_ctrl, &vctrl);
>>- if (!ret)
>>- ret = 1; /* Indicate control was changed w/o error */
>>- }
>>- snd_cx18_unlock(cxsc);
>>-
>>- return ret;
>>-}
>>-
>>
>>/* This is a bit of overkill, the slider is already in dB internally */
>>static DECLARE_TLV_DB_SCALE(snd_cx18_mixer_tv_vol_db_scale, -9600, 100,
>>0);
>
> Really? Did you try to compile the file after this patch?
>
> http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/pci/cx18/cx18-alsa-mixer.c#n143
>
> They are referenced later in the same file.
>
> This is only half a fix.
>
> You can either remove the cx18-alsa-mixer.* files and from the build system,
> or even better,you can hook-up and initialize these callbacks with alsa so
> alsa mixer controls show up for cx18. :)
>
Hi
Ok sorry :-(
Sure, I compile everything as allyesconfig, allmodconfig and allnoconfig.
So snd_cx18_mixer_tv_volume_info is the same as snd_cx18_mixer_tv_vol_info then.
Would gladly done something a little more concrete.
But first I want to see if as I can go through all of the
approximately 2000 functions that are not in use.
Kind regards
Rickard Strandqvist
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] one vdso fix for x86/urgent
Hi Ingo, etc, Please consider pulling for x86/urgent. This fixes a longstanding, albeit relatively minor, issue in the x86 vdso randomization algorithm. Note that this isn't super-urgent, as this bug isn't directly exploitable, and it's as old as the vdso itself. Thanks, Andy The following changes since commit e589c9e13aeb0c5539bf1314b3a78442ea8fc0c2: Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2014-12-19 14:02:02 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git tags/pr-20141220-x86-vdso for you to fetch changes up to 394f56fe480140877304d342dec46d50dc823d46: x86_64, vdso: Fix the vdso address randomization algorithm (2014-12-20 16:56:57 -0800) One vdso fix for a longstanding ASLR bug that's been in the news lately. The vdso base address has always been randomized, and I don't think there's anything particularly wrong with the range over which it's randomized, but the implementation seems to have been buggy since the very beginning. This fixes the implementation to remove a large bias that caused a small fraction of possible vdso load addresess to be vastly more likely than the rest of the possible addresses. Andy Lutomirski (1): x86_64, vdso: Fix the vdso address randomization algorithm arch/x86/vdso/vma.c | 45 + 1 file changed, 29 insertions(+), 16 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: pci: cx18: cx18-alsa-mixer.c: Remove some unused functions
On December 20, 2014 5:35:17 PM EST, Rickard Strandqvist
wrote:
>Removes some functions that are not used anywhere:
>snd_cx18_mixer_tv_vol_get() snd_cx18_mixer_tv_vol_info()
>snd_cx18_mixer_tv_vol_put()
>
>This was partially found by using a static code analysis program called
>cppcheck.
>
>Signed-off-by: Rickard Strandqvist
>
>---
>drivers/media/pci/cx18/cx18-alsa-mixer.c | 62
>--
> 1 file changed, 62 deletions(-)
>
>diff --git a/drivers/media/pci/cx18/cx18-alsa-mixer.c
>b/drivers/media/pci/cx18/cx18-alsa-mixer.c
>index 341bddc..e7b0a1f 100644
>--- a/drivers/media/pci/cx18/cx18-alsa-mixer.c
>+++ b/drivers/media/pci/cx18/cx18-alsa-mixer.c
>@@ -69,68 +69,6 @@ static inline int cx18_av_vol_to_dB(int v)
> return (v >> 9) - 119;
> }
>
>-static int snd_cx18_mixer_tv_vol_info(struct snd_kcontrol *kcontrol,
>-struct snd_ctl_elem_info *uinfo)
>-{
>- uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
>- uinfo->count = 1;
>- /* We're already translating values, just keep this control in dB */
>- uinfo->value.integer.min = -96;
>- uinfo->value.integer.max = 8;
>- uinfo->value.integer.step = 1;
>- return 0;
>-}
>-
>-static int snd_cx18_mixer_tv_vol_get(struct snd_kcontrol *kctl,
>- struct snd_ctl_elem_value *uctl)
>-{
>- struct snd_cx18_card *cxsc = snd_kcontrol_chip(kctl);
>- struct cx18 *cx = to_cx18(cxsc->v4l2_dev);
>- struct v4l2_control vctrl;
>- int ret;
>-
>- vctrl.id = V4L2_CID_AUDIO_VOLUME;
>- vctrl.value = dB_to_cx18_av_vol(uctl->value.integer.value[0]);
>-
>- snd_cx18_lock(cxsc);
>- ret = v4l2_subdev_call(cx->sd_av, core, g_ctrl, &vctrl);
>- snd_cx18_unlock(cxsc);
>-
>- if (!ret)
>- uctl->value.integer.value[0] = cx18_av_vol_to_dB(vctrl.value);
>- return ret;
>-}
>-
>-static int snd_cx18_mixer_tv_vol_put(struct snd_kcontrol *kctl,
>- struct snd_ctl_elem_value *uctl)
>-{
>- struct snd_cx18_card *cxsc = snd_kcontrol_chip(kctl);
>- struct cx18 *cx = to_cx18(cxsc->v4l2_dev);
>- struct v4l2_control vctrl;
>- int ret;
>-
>- vctrl.id = V4L2_CID_AUDIO_VOLUME;
>- vctrl.value = dB_to_cx18_av_vol(uctl->value.integer.value[0]);
>-
>- snd_cx18_lock(cxsc);
>-
>- /* Fetch current state */
>- ret = v4l2_subdev_call(cx->sd_av, core, g_ctrl, &vctrl);
>-
>- if (ret ||
>- (cx18_av_vol_to_dB(vctrl.value) != uctl->value.integer.value[0]))
>{
>-
>- /* Set, if needed */
>- vctrl.value = dB_to_cx18_av_vol(uctl->value.integer.value[0]);
>- ret = v4l2_subdev_call(cx->sd_av, core, s_ctrl, &vctrl);
>- if (!ret)
>- ret = 1; /* Indicate control was changed w/o error */
>- }
>- snd_cx18_unlock(cxsc);
>-
>- return ret;
>-}
>-
>
>/* This is a bit of overkill, the slider is already in dB internally */
>static DECLARE_TLV_DB_SCALE(snd_cx18_mixer_tv_vol_db_scale, -9600, 100,
>0);
Really? Did you try to compile the file after this patch?
http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/pci/cx18/cx18-alsa-mixer.c#n143
They are referenced later in the same file.
This is only half a fix.
You can either remove the cx18-alsa-mixer.* files and from the build system,
or even better,you can hook-up and initialize these callbacks with alsa so alsa
mixer controls show up for cx18. :)
-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: wireless: rtlwifi: rtl8723be: phy.c: Remove unused function
On 12/20/2014 04:59 PM, Rickard Strandqvist wrote:
Remove the function rtl8723be_phy_get_txpower_level() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/net/wireless/rtlwifi/rtl8723be/phy.c | 25 -
drivers/net/wireless/rtlwifi/rtl8723be/phy.h |2 --
2 files changed, 27 deletions(-)
Acked-by: Larry Finger
Larry
diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/phy.c
b/drivers/net/wireless/rtlwifi/rtl8723be/phy.c
index 20dcc25..b7b73cb 100644
--- a/drivers/net/wireless/rtlwifi/rtl8723be/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8723be/phy.c
@@ -874,31 +874,6 @@ void rtl8723be_phy_get_hw_reg_originalvalue(struct
ieee80211_hw *hw)
ROFDM0_RXDETECTOR3, rtlphy->framesync);
}
-void rtl8723be_phy_get_txpower_level(struct ieee80211_hw *hw, long *powerlevel)
-{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
- struct rtl_phy *rtlphy = &rtlpriv->phy;
- u8 txpwr_level;
- long txpwr_dbm;
-
- txpwr_level = rtlphy->cur_cck_txpwridx;
- txpwr_dbm = rtl8723_phy_txpwr_idx_to_dbm(hw, WIRELESS_MODE_B,
-txpwr_level);
- txpwr_level = rtlphy->cur_ofdm24g_txpwridx;
- if (rtl8723_phy_txpwr_idx_to_dbm(hw, WIRELESS_MODE_G, txpwr_level) >
- txpwr_dbm)
- txpwr_dbm =
- rtl8723_phy_txpwr_idx_to_dbm(hw, WIRELESS_MODE_G,
-txpwr_level);
- txpwr_level = rtlphy->cur_ofdm24g_txpwridx;
- if (rtl8723_phy_txpwr_idx_to_dbm(hw, WIRELESS_MODE_N_24G,
-txpwr_level) > txpwr_dbm)
- txpwr_dbm =
- rtl8723_phy_txpwr_idx_to_dbm(hw, WIRELESS_MODE_N_24G,
-txpwr_level);
- *powerlevel = txpwr_dbm;
-}
-
static u8 _rtl8723be_phy_get_ratesection_intxpower_byrate(enum radio_path
path,
u8 rate)
{
diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/phy.h
b/drivers/net/wireless/rtlwifi/rtl8723be/phy.h
index 6339738..9021d47 100644
--- a/drivers/net/wireless/rtlwifi/rtl8723be/phy.h
+++ b/drivers/net/wireless/rtlwifi/rtl8723be/phy.h
@@ -114,8 +114,6 @@ bool rtl8723be_phy_mac_config(struct ieee80211_hw *hw);
bool rtl8723be_phy_bb_config(struct ieee80211_hw *hw);
bool rtl8723be_phy_rf_config(struct ieee80211_hw *hw);
void rtl8723be_phy_get_hw_reg_originalvalue(struct ieee80211_hw *hw);
-void rtl8723be_phy_get_txpower_level(struct ieee80211_hw *hw,
-long *powerlevel);
void rtl8723be_phy_set_txpower_level(struct ieee80211_hw *hw,
u8 channel);
void rtl8723be_phy_scan_operation_backup(struct ieee80211_hw *hw,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: wireless: brcm80211: brcmsmac: phy: phy_n.c: Remove unused function
Remove the function wlc_phy_txpwr_idx_get_nphy() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
.../net/wireless/brcm80211/brcmsmac/phy/phy_int.h |1 -
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c | 19 ---
2 files changed, 20 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
index 4960f7d..c3d4f17 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
@@ -1104,7 +1104,6 @@ void wlc_phy_txpwrctrl_enable_nphy(struct brcms_phy *pi,
u8 ctrl_type);
void wlc_phy_txpwr_fixpower_nphy(struct brcms_phy *pi);
void wlc_phy_txpwr_apply_nphy(struct brcms_phy *pi);
void wlc_phy_txpwr_papd_cal_nphy(struct brcms_phy *pi);
-u16 wlc_phy_txpwr_idx_get_nphy(struct brcms_phy *pi);
struct nphy_txgains wlc_phy_get_tx_gain_nphy(struct brcms_phy *pi);
int wlc_phy_cal_txiqlo_nphy(struct brcms_phy *pi,
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
index 084f18f..44cb2f0 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
@@ -28257,25 +28257,6 @@ static bool wlc_phy_txpwr_ison_nphy(struct brcms_phy
*pi)
(0x1 << 14) | (0x1 << 13));
}
-u16 wlc_phy_txpwr_idx_get_nphy(struct brcms_phy *pi)
-{
- u16 tmp;
- u16 pwr_idx[2];
-
- if (wlc_phy_txpwr_ison_nphy(pi)) {
- pwr_idx[0] = wlc_phy_txpwr_idx_cur_get_nphy(pi, PHY_CORE_0);
- pwr_idx[1] = wlc_phy_txpwr_idx_cur_get_nphy(pi, PHY_CORE_1);
-
- tmp = (pwr_idx[0] << 8) | pwr_idx[1];
- } else {
- tmp = ((pi->nphy_txpwrindex[PHY_CORE_0].index_internal & 0xff)
- << 8) |
- (pi->nphy_txpwrindex[PHY_CORE_1].index_internal & 0xff);
- }
-
- return tmp;
-}
-
void wlc_phy_txpwr_papd_cal_nphy(struct brcms_phy *pi)
{
if (PHY_IPA(pi)
--
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] net: wireless: brcm80211: brcmsmac: phy: phy_lcn.c: Remove unused function
Remove the function wlc_lcnphy_crsuprs() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
.../net/wireless/brcm80211/brcmsmac/phy/phy_int.h |1 -
.../net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c | 31
2 files changed, 32 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
index 4960f7d..a05dbde 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
@@ -1002,7 +1002,6 @@ s16 wlc_lcnphy_tempsense_new(struct brcms_phy *pi, bool
mode);
s8 wlc_lcnphy_tempsense_degree(struct brcms_phy *pi, bool mode);
s8 wlc_lcnphy_vbatsense(struct brcms_phy *pi, bool mode);
void wlc_phy_carrier_suppress_lcnphy(struct brcms_phy *pi);
-void wlc_lcnphy_crsuprs(struct brcms_phy *pi, int channel);
void wlc_lcnphy_epa_switch(struct brcms_phy *pi, bool mode);
void wlc_2064_vco_cal(struct brcms_phy *pi);
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
index 5f13662..d2adb2d 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
@@ -1546,37 +1546,6 @@ s8 wlc_lcnphy_get_current_tx_pwr_idx(struct brcms_phy
*pi)
return index;
}
-void wlc_lcnphy_crsuprs(struct brcms_phy *pi, int channel)
-{
- u16 afectrlovr, afectrlovrval;
- afectrlovr = read_phy_reg(pi, 0x43b);
- afectrlovrval = read_phy_reg(pi, 0x43c);
- if (channel != 0) {
- mod_phy_reg(pi, 0x43b, (0x1 << 1), (1) << 1);
-
- mod_phy_reg(pi, 0x43c, (0x1 << 1), (0) << 1);
-
- mod_phy_reg(pi, 0x43b, (0x1 << 4), (1) << 4);
-
- mod_phy_reg(pi, 0x43c, (0x1 << 6), (0) << 6);
-
- write_phy_reg(pi, 0x44b, 0x);
- wlc_lcnphy_tx_pu(pi, 1);
-
- mod_phy_reg(pi, 0x634, (0xff << 8), (0) << 8);
-
- or_phy_reg(pi, 0x6da, 0x0080);
-
- or_phy_reg(pi, 0x00a, 0x228);
- } else {
- and_phy_reg(pi, 0x00a, ~(0x228));
-
- and_phy_reg(pi, 0x6da, 0xFF7F);
- write_phy_reg(pi, 0x43b, afectrlovr);
- write_phy_reg(pi, 0x43c, afectrlovrval);
- }
-}
-
static void wlc_lcnphy_toggle_afe_pwdn(struct brcms_phy *pi)
{
u16 save_AfeCtrlOvrVal, save_AfeCtrlOvr;
--
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 v3] net: wireless: brcm80211: brcmsmac: phy: phy_cmn.c: Remove some unused functions
Removes some functions that are not used anywhere:
wlc_phy_edcrs_lock() wlc_phy_txpower_ipa_ison() wlc_phy_upd_rssi_offset()
wlc_phy_get_pwrdet_offsets() wlc_lcnphy_epa_switch() wlc_phy_stf_ssmode_get()
wlc_phy_stf_chain_get() write_phy_channel_reg() wlc_phy_BSSinit()
wlc_phy_set_deaf() wlc_phy_freqtrack_end() wlc_phy_freqtrack_start()
wlc_phy_noise_sample_request_external() wlc_phy_test_ison()
wlc_phy_txpower_hw_ctrl_set() wlc_phy_bf_preempt_enable()
wlc_phy_runbist_config() wlc_phy_txpwr_percent_set()
wlc_phy_txpower_get_target_max() wlc_radioreg_exit()
wlc_phy_txpower_get_target_min() wlc_phy_txpower_boardlimit_band()
wlc_phy_txpower_sromlimit_max_get() wlc_radioreg_enter()
wlc_phy_txpower_target_set() wlc_phy_chanspec_band_firstch()
wlc_phy_chanspec_bandrange_get() wlc_phy_bw_state_get() wlc_phy_clear_tssi()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
.../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 433
.../net/wireless/brcm80211/brcmsmac/phy/phy_hal.h | 29 --
.../net/wireless/brcm80211/brcmsmac/phy/phy_int.h |8 -
3 files changed, 470 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
index 941b1e4..af428bb 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
@@ -138,23 +138,6 @@ void wlc_phyreg_exit(struct brcms_phy_pub *pih)
wlapi_bmac_ucode_wake_override_phyreg_clear(pi->sh->physhim);
}
-void wlc_radioreg_enter(struct brcms_phy_pub *pih)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
- wlapi_bmac_mctrl(pi->sh->physhim, MCTL_LOCK_RADIO, MCTL_LOCK_RADIO);
-
- udelay(10);
-}
-
-void wlc_radioreg_exit(struct brcms_phy_pub *pih)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
-
- (void)bcma_read16(pi->d11core, D11REGOFFS(phyversion));
- pi->phy_wreg = 0;
- wlapi_bmac_mctrl(pi->sh->physhim, MCTL_LOCK_RADIO, 0);
-}
-
u16 read_radio_reg(struct brcms_phy *pi, u16 addr)
{
u16 data;
@@ -274,11 +257,6 @@ void mod_radio_reg(struct brcms_phy *pi, u16 addr, u16
mask, u16 val)
write_radio_reg(pi, addr, (rval & ~mask) | (val & mask));
}
-void write_phy_channel_reg(struct brcms_phy *pi, uint val)
-{
- bcma_write16(pi->d11core, D11REGOFFS(phychannel), val);
-}
-
u16 read_phy_reg(struct brcms_phy *pi, u16 addr)
{
bcma_wflush16(pi->d11core, D11REGOFFS(phyregaddr), addr);
@@ -703,18 +681,6 @@ void wlc_phy_por_inform(struct brcms_phy_pub *ppi)
pi->phy_init_por = true;
}
-void wlc_phy_edcrs_lock(struct brcms_phy_pub *pih, bool lock)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
-
- pi->edcrs_threshold_lock = lock;
-
- write_phy_reg(pi, 0x22c, 0x46b);
- write_phy_reg(pi, 0x22d, 0x46b);
- write_phy_reg(pi, 0x22e, 0x3c0);
- write_phy_reg(pi, 0x22f, 0x3c0);
-}
-
void wlc_phy_initcal_enable(struct brcms_phy_pub *pih, bool initcal)
{
struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
@@ -1094,20 +1060,6 @@ void wlc_phy_mute_upd(struct brcms_phy_pub *pih, bool
mute, u32 flags)
return;
}
-void wlc_phy_clear_tssi(struct brcms_phy_pub *pih)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
-
- if (ISNPHY(pi)) {
- return;
- } else {
- wlapi_bmac_write_shm(pi->sh->physhim, M_B_TSSI_0, NULL_TSSI_W);
- wlapi_bmac_write_shm(pi->sh->physhim, M_B_TSSI_1, NULL_TSSI_W);
- wlapi_bmac_write_shm(pi->sh->physhim, M_G_TSSI_0, NULL_TSSI_W);
- wlapi_bmac_write_shm(pi->sh->physhim, M_G_TSSI_1, NULL_TSSI_W);
- }
-}
-
static bool wlc_phy_cal_txpower_recalc_sw(struct brcms_phy *pi)
{
return false;
@@ -1147,13 +1099,6 @@ void wlc_phy_switch_radio(struct brcms_phy_pub *pih,
bool on)
}
}
-u16 wlc_phy_bw_state_get(struct brcms_phy_pub *ppi)
-{
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
-
- return pi->bw;
-}
-
void wlc_phy_bw_state_set(struct brcms_phy_pub *ppi, u16 bw)
{
struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
@@ -1209,20 +1154,6 @@ int wlc_phy_chanspec_freq2bandrange_lpssn(uint freq)
return range;
}
-int wlc_phy_chanspec_bandrange_get(struct brcms_phy *pi, u16 chanspec)
-{
- int range = -1;
- uint channel = CHSPEC_CHANNEL(chanspec);
- uint freq = wlc_phy_channel2freq(channel);
-
- if (ISNPHY(pi))
- range = wlc_phy_get_chan_freq_range_nphy(pi, channel);
- else if (ISLCNPHY(pi))
- range = wlc_phy_chanspec_freq2bandrange_lpssn(freq);
-
- return range;
-}
-
void wlc_phy_chanspec_ch14_widefilter_set(struct brcms_phy_pub *ppi,
Re: [PATCH v2] net: wireless: brcm80211: brcmsmac: phy: phy_cmn.c: Remove some unused functions
2014-12-21 1:09 GMT+01:00 Rickard Strandqvist : > Removes some functions that are not used anywhere: > wlc_phy_edcrs_lock() wlc_phy_txpower_ipa_ison() wlc_phy_upd_rssi_offset() > wlc_phy_get_pwrdet_offsets() wlc_lcnphy_epa_switch() wlc_phy_stf_ssmode_get() > wlc_phy_stf_chain_get() write_phy_channel_reg() wlc_phy_BSSinit() > wlc_phy_set_deaf() wlc_phy_freqtrack_end() wlc_phy_freqtrack_start() > wlc_phy_noise_sample_request_external() wlc_phy_test_ison() > wlc_phy_txpower_hw_ctrl_set() wlc_phy_bf_preempt_enable() > wlc_phy_runbist_config() wlc_phy_txpwr_percent_set() > wlc_phy_txpower_get_target_max() wlc_radioreg_exit() > wlc_phy_txpower_get_target_min() wlc_phy_txpower_boardlimit_band() > wlc_phy_txpower_sromlimit_max_get() wlc_radioreg_enter() > wlc_phy_txpower_target_set() wlc_phy_chanspec_band_firstch() > wlc_phy_chanspec_bandrange_get() wlc_phy_bw_state_get() wlc_phy_clear_tssi() Hi Sorry! Wrong again :( wlc_lcnphy_crsuprs () should not be removed from hedder file. V2 was the same problem with wlc_phy_txpwr_idx_get_nphy() A new V3 comes in same minute. Kind regards Rickard Strandqvist -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel 3.17.x Attaching Keyspan 4-Port Serial to USB Adapter Causes Kernel Panic
On a new Gentoo based system with Kernel.org Kernels 3.17.4 to 3.17.7 when I physically plug the Keyspan 4-Port Serial to USB adapter into a usb port my system freezes with a "unable to handle kernel NULL pointer deference" message. My old system (also Gentoo based with Kernel.org 3.17.4) does not have this issue. Both systems are using the USB_SERIAL_KEYSPAN_USA49W driver module. I tried booting into single user mode, using modprobe to load USB_SERIAL_KEYSPAN_USA49W. lsmod shows the driver. When I pluged the device in I receive the system freeze. Below is what I copied off the console ... BUG: Unable to handle kernel NULL pointer deference at 000...8c IP: [] usa49_instat_callback+0x4d/0xb0[keyspan] PGD 1037faa067 PUD 1038301067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: keyspan ezusb usbserial hid_generic ... ... Hardware name: ASUS All Series/X99-A, BIOS 1004 10/16/2014 If I can provide any more information, please ask. Please CC my e-mail address with any replies, I do not subscribe to the linux kernel list: richj...@pacbell.net Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] net: wireless: brcm80211: brcmsmac: phy: phy_cmn.c: Remove some unused functions
Removes some functions that are not used anywhere:
wlc_phy_edcrs_lock() wlc_phy_txpower_ipa_ison() wlc_phy_upd_rssi_offset()
wlc_phy_get_pwrdet_offsets() wlc_lcnphy_epa_switch() wlc_phy_stf_ssmode_get()
wlc_phy_stf_chain_get() write_phy_channel_reg() wlc_phy_BSSinit()
wlc_phy_set_deaf() wlc_phy_freqtrack_end() wlc_phy_freqtrack_start()
wlc_phy_noise_sample_request_external() wlc_phy_test_ison()
wlc_phy_txpower_hw_ctrl_set() wlc_phy_bf_preempt_enable()
wlc_phy_runbist_config() wlc_phy_txpwr_percent_set()
wlc_phy_txpower_get_target_max() wlc_radioreg_exit()
wlc_phy_txpower_get_target_min() wlc_phy_txpower_boardlimit_band()
wlc_phy_txpower_sromlimit_max_get() wlc_radioreg_enter()
wlc_phy_txpower_target_set() wlc_phy_chanspec_band_firstch()
wlc_phy_chanspec_bandrange_get() wlc_phy_bw_state_get() wlc_phy_clear_tssi()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
.../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 433
.../net/wireless/brcm80211/brcmsmac/phy/phy_hal.h | 29 --
.../net/wireless/brcm80211/brcmsmac/phy/phy_int.h |9 -
3 files changed, 471 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
index 941b1e4..af428bb 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
@@ -138,23 +138,6 @@ void wlc_phyreg_exit(struct brcms_phy_pub *pih)
wlapi_bmac_ucode_wake_override_phyreg_clear(pi->sh->physhim);
}
-void wlc_radioreg_enter(struct brcms_phy_pub *pih)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
- wlapi_bmac_mctrl(pi->sh->physhim, MCTL_LOCK_RADIO, MCTL_LOCK_RADIO);
-
- udelay(10);
-}
-
-void wlc_radioreg_exit(struct brcms_phy_pub *pih)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
-
- (void)bcma_read16(pi->d11core, D11REGOFFS(phyversion));
- pi->phy_wreg = 0;
- wlapi_bmac_mctrl(pi->sh->physhim, MCTL_LOCK_RADIO, 0);
-}
-
u16 read_radio_reg(struct brcms_phy *pi, u16 addr)
{
u16 data;
@@ -274,11 +257,6 @@ void mod_radio_reg(struct brcms_phy *pi, u16 addr, u16
mask, u16 val)
write_radio_reg(pi, addr, (rval & ~mask) | (val & mask));
}
-void write_phy_channel_reg(struct brcms_phy *pi, uint val)
-{
- bcma_write16(pi->d11core, D11REGOFFS(phychannel), val);
-}
-
u16 read_phy_reg(struct brcms_phy *pi, u16 addr)
{
bcma_wflush16(pi->d11core, D11REGOFFS(phyregaddr), addr);
@@ -703,18 +681,6 @@ void wlc_phy_por_inform(struct brcms_phy_pub *ppi)
pi->phy_init_por = true;
}
-void wlc_phy_edcrs_lock(struct brcms_phy_pub *pih, bool lock)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
-
- pi->edcrs_threshold_lock = lock;
-
- write_phy_reg(pi, 0x22c, 0x46b);
- write_phy_reg(pi, 0x22d, 0x46b);
- write_phy_reg(pi, 0x22e, 0x3c0);
- write_phy_reg(pi, 0x22f, 0x3c0);
-}
-
void wlc_phy_initcal_enable(struct brcms_phy_pub *pih, bool initcal)
{
struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
@@ -1094,20 +1060,6 @@ void wlc_phy_mute_upd(struct brcms_phy_pub *pih, bool
mute, u32 flags)
return;
}
-void wlc_phy_clear_tssi(struct brcms_phy_pub *pih)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
-
- if (ISNPHY(pi)) {
- return;
- } else {
- wlapi_bmac_write_shm(pi->sh->physhim, M_B_TSSI_0, NULL_TSSI_W);
- wlapi_bmac_write_shm(pi->sh->physhim, M_B_TSSI_1, NULL_TSSI_W);
- wlapi_bmac_write_shm(pi->sh->physhim, M_G_TSSI_0, NULL_TSSI_W);
- wlapi_bmac_write_shm(pi->sh->physhim, M_G_TSSI_1, NULL_TSSI_W);
- }
-}
-
static bool wlc_phy_cal_txpower_recalc_sw(struct brcms_phy *pi)
{
return false;
@@ -1147,13 +1099,6 @@ void wlc_phy_switch_radio(struct brcms_phy_pub *pih,
bool on)
}
}
-u16 wlc_phy_bw_state_get(struct brcms_phy_pub *ppi)
-{
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
-
- return pi->bw;
-}
-
void wlc_phy_bw_state_set(struct brcms_phy_pub *ppi, u16 bw)
{
struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
@@ -1209,20 +1154,6 @@ int wlc_phy_chanspec_freq2bandrange_lpssn(uint freq)
return range;
}
-int wlc_phy_chanspec_bandrange_get(struct brcms_phy *pi, u16 chanspec)
-{
- int range = -1;
- uint channel = CHSPEC_CHANNEL(chanspec);
- uint freq = wlc_phy_channel2freq(channel);
-
- if (ISNPHY(pi))
- range = wlc_phy_get_chan_freq_range_nphy(pi, channel);
- else if (ISLCNPHY(pi))
- range = wlc_phy_chanspec_freq2bandrange_lpssn(freq);
-
- return range;
-}
-
void wlc_phy_chanspec_ch14_widefilter_set(struct brcms_phy_pub *ppi,
[PATCH] hid: Fix battery support for the 2009 ANSI Apple wireless keyboard.
Enabled quirks necessary for correct battery capacity reporting. Cleaned up
surrounding style.
Signed-off-by: Ross Skaliotis
---
drivers/hid/hid-input.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index e0a0f06..146da43 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -306,10 +306,13 @@ static enum power_supply_property
hidinput_battery_props[] = {
static const struct hid_device_id hid_battery_quirks[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
- USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO),
- HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
+ USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO),
+ HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
+ USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI),
+ HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
- USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI),
+ USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI),
HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI),
--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bluetooth: Add hci_h4p driver
Hi Pavel, >>> I have trouble understanding... h4p_hci_open() seems to be called as >>> soon as I insmod the driver. Who does that? Is it some kind of udev >>> magic? >> >> As soon as you do hci_register_dev, it will bring up the device and run the >> basic initialization. That is needed to get the address, version information >> and features. Otherwise the mgmt interface can not work. We need basic >> information about the device. >> >> So what the kernel will do internally when you find a device is bring it up, >> get the basics and then bring it back down (in case nobody uses it). See >> hci_power_on work. >> > > Aha, slightly unexpected, but it matches observations. Good. we are at Bluetooth 4.2 specification now. Thinks got a lot more complicated these days. > >>> To use __hci_cmd_sync() >>> > + > + SET_HCIDEV_DEV(hdev, info->dev); > + > + if (hci_register_dev(hdev) >= 0) > + return 0; > + > + dev_err(info->dev, "hci_register failed %s.\n", hdev->name); > + hci_free_dev(info->hdev); > + return -ENODEV; > +} And normally this is folded into the probe handling and not in a separate function. >>> >>> The probe function is too long, already... >> >> Have you compared it to other functions. Normally probe() functions in >> general are all pretty long since they have to do tons of stuff. Having all >> in one function means you can read through it at once. >> > > Ok. > > +#include "hci_h4p.h" Why is this a separate file? And if so, why not all UART specific details are in this file. Including bunch of the defines you have in the header. >>> >>> Well, you wanted less global functions, so I moved some as inlines to >>> headers. I guess I can merge nokia_core and nokia_uart if really wanted. >> >> Would this become easier when some of the OMAP specific stuff is moved out >> of this driver? If that is possible. >> > > Yes, I can investigate further cleanups. But original plan was to > merge it and then clean up the rest. Could we do that, please? You need to fix all these small details. There are tons of whitespace damages, indentation issues, trailing whitespaces and what not. Even if they were in the original driver to begin this, they can not be in a driver submitted these days. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth: Add hci_h4p driver
Hi Pavel,
> Add hci_h4p bluetooth driver. This device is used for example on Nokia N900
> cell phone.
the driver is called nokia_h4p. And you could be a little bit more verbose here
explaining where the driver came from.
>
> Signed-off-by: Pavel Machek
> Thanks-to: Sebastian Reichel
> Thanks-to: Joe Perches
>
> ---
>
> Please apply,
If you refuse to use git check-patch, then manually include a diffstat.
>
> Pavel
>
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 4547dc2..268b1a6 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -243,4 +243,13 @@ config BT_WILINK
> Say Y here to compile support for Texas Instrument's WiLink7 driver
> into the kernel or say M to compile it as module (btwilink).
>
> +config BT_NOKIA_H4P
> + tristate "HCI driver with H4 Nokia extensions"
Lets call this "Nokia H4+ Extensions (H4P) driver"
I prefer if the driver list looks at least a bit clean. So that vendor drivers
that with the vendor name in their description.
> + help
> + Bluetooth HCI driver with H4 extensions. This driver provides
> + support for H4+ Bluetooth chip with vendor-specific H4 extensions.
Mention here that the current version supports the Broadcom based version found
in the Nokia N900.
> +
> + Say Y here to compile support for h4 extended devices into the kernel
> + or say M to compile it as module (btnokia_h4p).
Module name is nokia_h4p
> +
> endmenu
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index 9fe8a87..624ef3fc 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -31,4 +31,7 @@ hci_uart-$(CONFIG_BT_HCIUART_ATH3K) += hci_ath.o
> hci_uart-$(CONFIG_BT_HCIUART_3WIRE) += hci_h5.o
> hci_uart-objs := $(hci_uart-y)
>
> +obj-$(CONFIG_BT_NOKIA_H4P) += nokia_h4p.o
We use tabs and not spaces here.
Also add an extra empty line between the driver field and the list of objects.
> +nokia_h4p-objs := nokia_core.o nokia_fw.o nokia_uart.o
> +
And unless something changed in kbuild, this is nokia_h4p-y :=. Similar to all
the other multi file drivers we have.
> ccflags-y += -D__CHECK_ENDIAN__
> diff --git a/drivers/bluetooth/nokia_core.c b/drivers/bluetooth/nokia_core.c
> new file mode 100644
> index 000..163531e
> --- /dev/null
> +++ b/drivers/bluetooth/nokia_core.c
> @@ -0,0 +1,1188 @@
> +/*
> + * This file is part of Nokia H4P bluetooth driver
> + *
> + * Copyright (C) 2005-2008 Nokia Corporation.
> + * Copyright (C) 2014 Pavel Machek
> + *
> + * 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.
> + *
> + * 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 St, Fifth Floor, Boston, MA
> + * 02110-1301 USA
> + *
> + * Thanks to all the Nokia people that helped with this driver,
> + * including Ville Tervo and Roger Quadros.
> + *
> + * Power saving functionality was removed from this driver to make
> + * merging easier.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include "nokia_h4p.h"
> +
> +#undef TEST
What is the TEST undef doing here?
> +
> +static int hw_inited = 0;
> +
> +/* This should be used in function that cannot release clocks */
> +static void h4p_set_clk(struct h4p_info *info, int *clock, int enable)
Lets start using bool enable here.
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&info->clocks_lock, flags);
> + if (enable && !*clock) {
> + BT_DBG("Enabling %p", clock);
> + clk_prepare_enable(info->uart_fclk);
> + clk_prepare_enable(info->uart_iclk);
> + if (atomic_read(&info->clk_users) == 0)
> + h4p_restore_regs(info);
> + atomic_inc(&info->clk_users);
> + }
> +
> + if (!enable && *clock) {
> + BT_DBG("Disabling %p", clock);
> + if (atomic_dec_and_test(&info->clk_users))
> + h4p_store_regs(info);
> + clk_disable_unprepare(info->uart_fclk);
> + clk_disable_unprepare(info->uart_iclk);
> + }
> +
> + *clock = enable;
> + spin_unlock_irqrestore(&info->clock
[PATCH] vhost: relax used address alignment
virtio 1.0 only requires used address to be 4 byte aligned,
vhost required 8 bytes (size of vring_used_elem).
Fix up vhost to match that.
Additionally, while vhost correctly requires 8 byte
alignment for log, it's unconnected to used ring:
it's a consequence that log has u64 entries.
Tweak code to make that clearer.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vhost.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index ed71b53..97996fc 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -713,9 +713,12 @@ long vhost_vring_ioctl(struct vhost_dev *d, int ioctl,
void __user *argp)
r = -EFAULT;
break;
}
- if ((a.avail_user_addr & (sizeof *vq->avail->ring - 1)) ||
- (a.used_user_addr & (sizeof *vq->used->ring - 1)) ||
- (a.log_guest_addr & (sizeof *vq->used->ring - 1))) {
+
+ BUILD_BUG_ON(__alignof__ *vq->avail != 2);
+ BUILD_BUG_ON(__alignof__ *vq->used != 4);
+ if ((a.avail_user_addr & (__alignof__ *vq->avail - 1)) ||
+ (a.used_user_addr & (__alignof__ *vq->used - 1)) ||
+ (a.log_guest_addr & (sizeof(u64) - 1))) {
r = -EINVAL;
break;
}
--
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scsi: gdth_proc.c: Remove unused function
Remove the function gdth_ioctl_check_bin() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/scsi/gdth_proc.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/scsi/gdth_proc.c b/drivers/scsi/gdth_proc.c
index 9fb6326..efb9df5 100644
--- a/drivers/scsi/gdth_proc.c
+++ b/drivers/scsi/gdth_proc.c
@@ -598,24 +598,6 @@ static void gdth_ioctl_free(gdth_ha_str *ha, int size,
char *buf, u64 paddr)
}
}
-#ifdef GDTH_IOCTL_PROC
-static int gdth_ioctl_check_bin(gdth_ha_str *ha, u16 size)
-{
-unsigned long flags;
-int ret_val;
-
-spin_lock_irqsave(&ha->smp_lock, flags);
-
-ret_val = FALSE;
-if (ha->scratch_busy) {
-if (((gdth_iord_str *)ha->pscratch)->size == (u32)size)
-ret_val = TRUE;
-}
-spin_unlock_irqrestore(&ha->smp_lock, flags);
-return ret_val;
-}
-#endif
-
static void gdth_wait_completion(gdth_ha_str *ha, int busnum, int id)
{
unsigned long flags;
--
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] net: wireless: rtlwifi: rtl8723be: phy.c: Remove unused function
Remove the function rtl8723be_phy_get_txpower_level() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/net/wireless/rtlwifi/rtl8723be/phy.c | 25 -
drivers/net/wireless/rtlwifi/rtl8723be/phy.h |2 --
2 files changed, 27 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/phy.c
b/drivers/net/wireless/rtlwifi/rtl8723be/phy.c
index 20dcc25..b7b73cb 100644
--- a/drivers/net/wireless/rtlwifi/rtl8723be/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8723be/phy.c
@@ -874,31 +874,6 @@ void rtl8723be_phy_get_hw_reg_originalvalue(struct
ieee80211_hw *hw)
ROFDM0_RXDETECTOR3, rtlphy->framesync);
}
-void rtl8723be_phy_get_txpower_level(struct ieee80211_hw *hw, long *powerlevel)
-{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
- struct rtl_phy *rtlphy = &rtlpriv->phy;
- u8 txpwr_level;
- long txpwr_dbm;
-
- txpwr_level = rtlphy->cur_cck_txpwridx;
- txpwr_dbm = rtl8723_phy_txpwr_idx_to_dbm(hw, WIRELESS_MODE_B,
-txpwr_level);
- txpwr_level = rtlphy->cur_ofdm24g_txpwridx;
- if (rtl8723_phy_txpwr_idx_to_dbm(hw, WIRELESS_MODE_G, txpwr_level) >
- txpwr_dbm)
- txpwr_dbm =
- rtl8723_phy_txpwr_idx_to_dbm(hw, WIRELESS_MODE_G,
-txpwr_level);
- txpwr_level = rtlphy->cur_ofdm24g_txpwridx;
- if (rtl8723_phy_txpwr_idx_to_dbm(hw, WIRELESS_MODE_N_24G,
-txpwr_level) > txpwr_dbm)
- txpwr_dbm =
- rtl8723_phy_txpwr_idx_to_dbm(hw, WIRELESS_MODE_N_24G,
-txpwr_level);
- *powerlevel = txpwr_dbm;
-}
-
static u8 _rtl8723be_phy_get_ratesection_intxpower_byrate(enum radio_path path,
u8 rate)
{
diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/phy.h
b/drivers/net/wireless/rtlwifi/rtl8723be/phy.h
index 6339738..9021d47 100644
--- a/drivers/net/wireless/rtlwifi/rtl8723be/phy.h
+++ b/drivers/net/wireless/rtlwifi/rtl8723be/phy.h
@@ -114,8 +114,6 @@ bool rtl8723be_phy_mac_config(struct ieee80211_hw *hw);
bool rtl8723be_phy_bb_config(struct ieee80211_hw *hw);
bool rtl8723be_phy_rf_config(struct ieee80211_hw *hw);
void rtl8723be_phy_get_hw_reg_originalvalue(struct ieee80211_hw *hw);
-void rtl8723be_phy_get_txpower_level(struct ieee80211_hw *hw,
-long *powerlevel);
void rtl8723be_phy_set_txpower_level(struct ieee80211_hw *hw,
u8 channel);
void rtl8723be_phy_scan_operation_backup(struct ieee80211_hw *hw,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] arm64: dts: Add mediatek MT8173 SoC and evaluation board dts and Makefile
On 20 December 2014 at 20:07, Arnd Bergmann wrote: > On Wednesday 17 December 2014 15:01:29 Marc Zyngier wrote: >> Also it is worth noticing that given how GICV is placed, it will never >> work with 64K pages and virtualization. Pretty sad. > > Does this mean no VGIC support on this platform so you have to emulate it > in order to run virtual machines with 64K pages, or does it mean that > it's impossible to use that way because you can't emulate it? Currently having the guest use the generic timer requires an in-kernel GIC, because we don't provide an ABI for having the kernel say "here is a generic timer interrupt for the userspace emulated GIC". And at least for QEMU userspace the "virt" board doesn't provide any other kind of timer, so you'd need to add one if you wanted to use a userspace GIC. So for practical purposes "out-of-kernel GIC" is not a supported config for KVM+QEMU. -- PMM -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arch: ia64: kernel: irq_ia64.c: Remove some unused functions
Removes some functions that are not used anywhere:
rnat_consumption() inat_page_consumption() privilege_reg()
unimpl_daddr() privilege_op() rsv_reg_field() illegal_dep()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
arch/ia64/kvm/process.c | 70 ---
1 file changed, 70 deletions(-)
diff --git a/arch/ia64/kvm/process.c b/arch/ia64/kvm/process.c
index b039874..ab9d9e7 100644
--- a/arch/ia64/kvm/process.c
+++ b/arch/ia64/kvm/process.c
@@ -302,56 +302,6 @@ void illegal_op(struct kvm_vcpu *vcpu)
_general_exception(vcpu);
}
-/*
- * Illegal Dependency Fault
- * @ General Exception Vector
- * Refer to SDM Vol2 Table 5-6 & 8-1
- */
-void illegal_dep(struct kvm_vcpu *vcpu)
-{
- _general_exception(vcpu);
-}
-
-/*
- * Reserved Register/Field Fault
- * @ General Exception Vector
- * Refer to SDM Vol2 Table 5-6 & 8-1
- */
-void rsv_reg_field(struct kvm_vcpu *vcpu)
-{
- _general_exception(vcpu);
-}
-/*
- * Privileged Operation Fault
- * @ General Exception Vector
- * Refer to SDM Vol2 Table 5-6 & 8-1
- */
-
-void privilege_op(struct kvm_vcpu *vcpu)
-{
- _general_exception(vcpu);
-}
-
-/*
- * Unimplement Data Address Fault
- * @ General Exception Vector
- * Refer to SDM Vol2 Table 5-6 & 8-1
- */
-void unimpl_daddr(struct kvm_vcpu *vcpu)
-{
- _general_exception(vcpu);
-}
-
-/*
- * Privileged Register Fault
- * @ General Exception Vector
- * Refer to SDM Vol2 Table 5-6 & 8-1
- */
-void privilege_reg(struct kvm_vcpu *vcpu)
-{
- _general_exception(vcpu);
-}
-
/* Deal with
* Nat consumption vector
* Parameter:
@@ -370,26 +320,6 @@ static void _nat_consumption_fault(struct kvm_vcpu *vcpu,
u64 vadr,
}
/*
- * Instruction Nat Page Consumption Fault
- * @ Nat Consumption Vector
- * Refer to SDM Vol2 Table 5-6 & 8-1
- */
-void inat_page_consumption(struct kvm_vcpu *vcpu, u64 vadr)
-{
- _nat_consumption_fault(vcpu, vadr, INSTRUCTION);
-}
-
-/*
- * Register Nat Consumption Fault
- * @ Nat Consumption Vector
- * Refer to SDM Vol2 Table 5-6 & 8-1
- */
-void rnat_consumption(struct kvm_vcpu *vcpu)
-{
- _nat_consumption_fault(vcpu, 0, REGISTER);
-}
-
-/*
* Data Nat Page Consumption Fault
* @ Nat Consumption Vector
* Refer to SDM Vol2 Table 5-6 & 8-1
--
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] printk: add per console loglevel
This adds to to the console= command line options allowing the
addition of a per console log level setting.
examples,
console=ttyS0,ll4
console=tty0,ll6
This can be used on systems which have multiple serial consoles, but
it's desired for logging to be light on one and heavy on another.
Signed-off-by: Daniel Walker
---
Documentation/kernel-parameters.txt | 24 ++--
include/linux/console.h | 1 +
kernel/printk/console_cmdline.h | 9 +
kernel/printk/printk.c | 37 -
4 files changed, 60 insertions(+), 11 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 4df73da..7e65d5b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -696,30 +696,42 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
console=[KNL] Output console device and options.
- tty Use the virtual console device .
+ tty[,llX]Use the virtual console device .
- ttyS[,options]
- ttyUSB0[,options]
+ ttyS[,options][,llX]
+ ttyUSB0[,options][,llX]
Use the specified serial port. The options are of
the form "pnf", where "" is the baud rate,
"p" is parity ("n", "o", or "e"), "n" is number of
bits, and "f" is flow control ("r" for RTS or
omit it). Default is "9600n8".
+ "llX" explained below,
+
See Documentation/serial-console.txt for more
information. See
Documentation/networking/netconsole.txt for an
alternative.
- uart[8250],io,[,options]
- uart[8250],mmio,[,options]
+ uart[8250],io,[,options][,llX]
+ uart[8250],mmio,[,options][,llX]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later. The
options are the same as for ttyS, above.
- hvc Use the hypervisor console device . This is for
+
+ "llX" explained below,
+
+ hvc[,llX]
+ Use the hypervisor console device . This is for
both Xen and PowerPC hypervisors.
+ "llX" is used to define the loglevel per console. The
"X"
+ defines the loglevel number for this console. The usage
+ is similar to the "loglevel=" option, and the effect is
+ the same only per console. The "loglevel=" option takes
+ precedence of this option.
+
If the device connected to the port is not a TTY but a braille
device, prepend "brl," before the device type, for instance
console=brl,ttyS0
diff --git a/include/linux/console.h b/include/linux/console.h
index 7571a16..99020d5 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -118,6 +118,7 @@ static inline int con_debug_leave(void)
struct console {
charname[16];
+ int loglevel;
void(*write)(struct console *, const char *, unsigned);
int (*read)(struct console *, char *, unsigned);
struct tty_driver *(*device)(struct console *, int *);
diff --git a/kernel/printk/console_cmdline.h b/kernel/printk/console_cmdline.h
index cbd69d8..6f6f98f 100644
--- a/kernel/printk/console_cmdline.h
+++ b/kernel/printk/console_cmdline.h
@@ -3,11 +3,12 @@
struct console_cmdline
{
- charname[8];/* Name of the driver */
- int index; /* Minor dev. to use*/
- char*options; /* Options for the driver */
+ charname[8];/* Name of the driver */
+ int index; /* Minor dev. to use*/
+ int loglevel; /* Log level for this console */
+ char*options; /* Options for the driver */
#ifdef CONFIG_A11Y_BRAILLE_CONSOLE
- char*brl_options; /* Options for braille driver */
+ char*brl_options; /* Options for braille driver */
#endif
};
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 02d6b6d..218d94d 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1414,6 +1414,9 @@ static void call_console_drivers(int level, const char
*text, size_t len)
if (!cpu_online(smp_processor_id()) &&
!(con->flags & C
Re: ***UNCHECKED*** Re: [PATCH] arch: arm: mach-msm: smd.c: Remove some unused functions
On Thu, Dec 18, 2014 at 11:35:04PM +0100, Arnd Bergmann wrote: > On Thursday 18 December 2014 22:01:28 dwal...@fifo99.com wrote: > > On Tue, Dec 16, 2014 at 12:20:43AM +0100, Rickard Strandqvist wrote: > > > Hi > > > > > > My script looks for the same function name, so if they then would be > > > named exactly the same, they would come up. > > > > > > But I can not even find drivers/staging/dream/ or is this really new > > > code? > > > > Maybe it was deleted already .. > > It's been gone for over four years, after nobody worked on cleaning it up > for a while before that: > > commit 3414df8ca38b203c8a5ad8efc32d4a3836a0596d > Author: Greg Kroah-Hartman > Date: Fri Oct 29 12:42:18 2010 -0700 > > Staging: dream: remove dream driver and arch from tree > > This code is stalled, with no one working on it anymore, and the main > msm code is now going through the proper channels to get merged > correctly. > > So remove it as it contains a number of kernel information leaks and it > is doubtful if it even still builds anymore. > > Acked-by: Pavel Machek > Acked-by: Bryan Huntsman > Signed-off-by: Greg Kroah-Hartman Yeah, somehow still ended up in my 3.18 tree. Must have been a "git reset". Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] gpu: drm: ast: ast_dp501.c: Remove unused function
Remove the function ast_load_dp501_microcode() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/ast/ast_dp501.c | 12
drivers/gpu/drm/ast/ast_drv.h |1 -
2 files changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_dp501.c b/drivers/gpu/drm/ast/ast_dp501.c
index 76f07f3..28c977c 100644
--- a/drivers/gpu/drm/ast/ast_dp501.c
+++ b/drivers/gpu/drm/ast/ast_dp501.c
@@ -4,18 +4,6 @@
#include "ast_drv.h"
MODULE_FIRMWARE("ast_dp501_fw.bin");
-int ast_load_dp501_microcode(struct drm_device *dev)
-{
- struct ast_private *ast = dev->dev_private;
- static char *fw_name = "ast_dp501_fw.bin";
- int err;
- err = request_firmware(&ast->dp501_fw, fw_name, dev->dev);
- if (err)
- return err;
-
- return 0;
-}
-
static void send_ack(struct ast_private *ast)
{
u8 sendack;
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 86205a2..67a872d 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -393,7 +393,6 @@ void ast_post_gpu(struct drm_device *dev);
u32 ast_mindwm(struct ast_private *ast, u32 r);
void ast_moutdwm(struct ast_private *ast, u32 r, u32 v);
/* ast dp501 */
-int ast_load_dp501_microcode(struct drm_device *dev);
void ast_set_dp501_video_output(struct drm_device *dev, u8 mode);
bool ast_launch_m68k(struct drm_device *dev);
bool ast_backup_fw(struct drm_device *dev, u8 *addr, u32 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/
[PATCH] arch: cris: arch-v32: drivers: sync_serial.c: Remove unused function
Remove the function sync_data_avail_to_end() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
arch/cris/arch-v32/drivers/sync_serial.c | 20
1 file changed, 20 deletions(-)
diff --git a/arch/cris/arch-v32/drivers/sync_serial.c
b/arch/cris/arch-v32/drivers/sync_serial.c
index 5a14913..4781514 100644
--- a/arch/cris/arch-v32/drivers/sync_serial.c
+++ b/arch/cris/arch-v32/drivers/sync_serial.c
@@ -409,26 +409,6 @@ static inline int sync_data_avail(struct sync_port *port)
return avail;
}
-static inline int sync_data_avail_to_end(struct sync_port *port)
-{
- int avail;
- unsigned char *start;
- unsigned char *end;
-
- start = (unsigned char*)port->readp; /* cast away volatile */
- end = (unsigned char*)port->writep; /* cast away volatile */
- /* 0123456789 0123456789
-* - -
-* ^rp ^wp^wp ^rp
-*/
-
- if (end >= start)
- avail = end - start;
- else
- avail = port->flip + port->in_buffer_size - start;
- return avail;
-}
-
static int sync_serial_open(struct inode *inode, struct file *file)
{
int dev = iminor(inode);
--
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] arch: powerpc: platforms: embedded6xx: mpc7448_hpc2.c: Remove some unused functions
Removes some functions that are not used anywhere:
mpc7448_hpc2_halt() mpc7448_hpc2_power_off()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
index beeaf4a..df4ad95 100644
--- a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
+++ b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
@@ -156,17 +156,6 @@ void mpc7448_hpc2_restart(char *cmd)
for (;;) ; /* Spin until reset happens */
}
-void mpc7448_hpc2_power_off(void)
-{
- local_irq_disable();
- for (;;) ; /* No way to shut power off with software */
-}
-
-void mpc7448_hpc2_halt(void)
-{
- mpc7448_hpc2_power_off();
-}
-
/*
* Called very early, device-tree isn't unflattened
*/
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] pwm: kona: Fix incorrect enable, config, and disable procedures
On Wed, Dec 17, 2014 at 10:46 AM, Jonathan Richardson
wrote:
> The config procedure doesn't follow the spec which periodically results
> in failing to enable the output signal. This happens one in ten or
> twenty attempts. Following the spec and adding a 400ns delay in the
> appropriate locations resolves this problem. It also ensures that the
> signal transition is smooth.
This patch does not result in smooth transitions.
Please ensure that your commit message reflects the code.
>
> If config is called when the pwm is disabled and there is nothing to do,
> the while loop to calculate duty cycle and period doesn't need to be
> done. The function now just returns if the pwm state is disabled.
>
> The disable procedure now also follows the spec to ensure a smooth
> transition. Not following the spec can cause non-smooth transitions.
>
> The enable procedure now clears the enabled bit if enabling failed.
> Enabling can fail if an invalid duty cycle and period is set. This
> prevents the sysfs interface from reporting the pwm is enabled after a
> failed call to enable.
>
> Reviewed-by: Arun Ramamurthy
> Reviewed-by: Scott Branden
> Tested-by: Scott Branden
> Signed-off-by: Jonathan Richardson
Normally when people send a multi-part patch series they include a
cover letter that describes the overall purpose of the changes with a
description of changes introduced in each revision of the series.
Please follow this convention.
> ---
> drivers/pwm/pwm-bcm-kona.c | 91
>
> 1 file changed, 67 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
> index 02bc048..a831bb2 100644
> --- a/drivers/pwm/pwm-bcm-kona.c
> +++ b/drivers/pwm/pwm-bcm-kona.c
> @@ -80,15 +80,19 @@ static void kona_pwmc_apply_settings(struct kona_pwmc
> *kp, unsigned int chan)
> {
> unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);
>
> - /* Clear trigger bit but set smooth bit to maintain old output */
> - value |= 1 << PWM_CONTROL_SMOOTH_SHIFT(chan);
> - value &= ~(1 << PWM_CONTROL_TRIGGER_SHIFT(chan));
> - writel(value, kp->base + PWM_CONTROL_OFFSET);
> + /*
> +* There must be a min 400ns delay between clearing enable and setting
> +* it. Failing to do this may result in no PWM signal.
> +*/
> + ndelay(400);
>
> /* Set trigger bit and clear smooth bit to apply new settings */
> value &= ~(1 << PWM_CONTROL_SMOOTH_SHIFT(chan));
> value |= 1 << PWM_CONTROL_TRIGGER_SHIFT(chan);
> writel(value, kp->base + PWM_CONTROL_OFFSET);
> +
> + /* PWMOUT_ENABLE must be held high for at least 400 ns. */
> + ndelay(400);
> }
>
Can you try to get a better understanding of what these timing
requirements actually are?
When I wrote this driver, the documentation simply stated that if the
trigger bit didn't stay high for 400 ns then the new settings would
not get applied.
It wasn't essential that we wait 400 ns here because the only time
when the trigger bit would be lowered is when we were about to load
even newer settings which meant we didn't care if the previous
settings were lost.
> static int kona_pwmc_config(struct pwm_chip *chip, struct pwm_device *pwm,
> @@ -99,6 +103,9 @@ static int kona_pwmc_config(struct pwm_chip *chip, struct
> pwm_device *pwm,
> unsigned long prescale = PRESCALE_MIN, pc, dc;
> unsigned int value, chan = pwm->hwpwm;
>
> + if (!test_bit(PWMF_ENABLED, &pwm->flags))
> + return 0;
> +
> /*
> * Find period count, duty count and prescale to suit duty_ns and
> * period_ns. This is done according to formulas described below:
Like I said last time, this is wrong. You need to sanity check the
requested period and duty cycle here.
You can't just return success immediately when the channel isn't enabled.
> @@ -121,31 +128,60 @@ static int kona_pwmc_config(struct pwm_chip *chip,
> struct pwm_device *pwm,
> dc = div64_u64(val, div);
>
> /* If duty_ns or period_ns are not achievable then return */
> - if (pc < PERIOD_COUNT_MIN || dc < DUTY_CYCLE_HIGH_MIN)
> + if (pc < PERIOD_COUNT_MIN) {
> + dev_warn(chip->dev,
> + "%s: pwm[%d]: period=%d is not achievable,
> pc=%lu, prescale=%lu\n",
> + __func__, chan, period_ns, pc, prescale);
> return -EINVAL;
> + }
> +
> + /* If duty_ns is not achievable then return */
> + if (dc < DUTY_CYCLE_HIGH_MIN) {
> + if (0 != duty_ns) {
> + dev_warn(chip->dev,
> + "%s: pwm[%d]: duty cycle=%d is not
> achievable, dc=%lu, prescale=%lu\n",
> +
[PATCH] net: ceph: armor.c: Remove unused function
Remove the function ceph_armor() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
net/ceph/armor.c | 39 ---
net/ceph/crypto.h |1 -
2 files changed, 40 deletions(-)
diff --git a/net/ceph/armor.c b/net/ceph/armor.c
index 1fc1ee1..05e0d2b 100644
--- a/net/ceph/armor.c
+++ b/net/ceph/armor.c
@@ -1,7 +1,6 @@
#include
-int ceph_armor(char *dst, const char *src, const char *end);
int ceph_unarmor(char *dst, const char *src, const char *end);
/*
@@ -33,44 +32,6 @@ static int decode_bits(char c)
return -EINVAL;
}
-int ceph_armor(char *dst, const char *src, const char *end)
-{
- int olen = 0;
- int line = 0;
-
- while (src < end) {
- unsigned char a, b, c;
-
- a = *src++;
- *dst++ = encode_bits(a >> 2);
- if (src < end) {
- b = *src++;
- *dst++ = encode_bits(((a & 3) << 4) | (b >> 4));
- if (src < end) {
- c = *src++;
- *dst++ = encode_bits(((b & 15) << 2) |
-(c >> 6));
- *dst++ = encode_bits(c & 63);
- } else {
- *dst++ = encode_bits((b & 15) << 2);
- *dst++ = '=';
- }
- } else {
- *dst++ = encode_bits(((a & 3) << 4));
- *dst++ = '=';
- *dst++ = '=';
- }
- olen += 4;
- line += 4;
- if (line == 64) {
- line = 0;
- *(dst++) = '\n';
- olen++;
- }
- }
- return olen;
-}
-
int ceph_unarmor(char *dst, const char *src, const char *end)
{
int olen = 0;
diff --git a/net/ceph/crypto.h b/net/ceph/crypto.h
index d149822..5cbc7b1 100644
--- a/net/ceph/crypto.h
+++ b/net/ceph/crypto.h
@@ -45,7 +45,6 @@ int ceph_crypto_init(void);
void ceph_crypto_shutdown(void);
/* armor.c */
-int ceph_armor(char *dst, const char *src, const char *end);
int ceph_unarmor(char *dst, const char *src, const char *end);
#endif
--
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] media: pci: cx18: cx18-alsa-mixer.c: Remove some unused functions
Removes some functions that are not used anywhere:
snd_cx18_mixer_tv_vol_get() snd_cx18_mixer_tv_vol_info()
snd_cx18_mixer_tv_vol_put()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/media/pci/cx18/cx18-alsa-mixer.c | 62 --
1 file changed, 62 deletions(-)
diff --git a/drivers/media/pci/cx18/cx18-alsa-mixer.c
b/drivers/media/pci/cx18/cx18-alsa-mixer.c
index 341bddc..e7b0a1f 100644
--- a/drivers/media/pci/cx18/cx18-alsa-mixer.c
+++ b/drivers/media/pci/cx18/cx18-alsa-mixer.c
@@ -69,68 +69,6 @@ static inline int cx18_av_vol_to_dB(int v)
return (v >> 9) - 119;
}
-static int snd_cx18_mixer_tv_vol_info(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_info *uinfo)
-{
- uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
- uinfo->count = 1;
- /* We're already translating values, just keep this control in dB */
- uinfo->value.integer.min = -96;
- uinfo->value.integer.max = 8;
- uinfo->value.integer.step = 1;
- return 0;
-}
-
-static int snd_cx18_mixer_tv_vol_get(struct snd_kcontrol *kctl,
-struct snd_ctl_elem_value *uctl)
-{
- struct snd_cx18_card *cxsc = snd_kcontrol_chip(kctl);
- struct cx18 *cx = to_cx18(cxsc->v4l2_dev);
- struct v4l2_control vctrl;
- int ret;
-
- vctrl.id = V4L2_CID_AUDIO_VOLUME;
- vctrl.value = dB_to_cx18_av_vol(uctl->value.integer.value[0]);
-
- snd_cx18_lock(cxsc);
- ret = v4l2_subdev_call(cx->sd_av, core, g_ctrl, &vctrl);
- snd_cx18_unlock(cxsc);
-
- if (!ret)
- uctl->value.integer.value[0] = cx18_av_vol_to_dB(vctrl.value);
- return ret;
-}
-
-static int snd_cx18_mixer_tv_vol_put(struct snd_kcontrol *kctl,
-struct snd_ctl_elem_value *uctl)
-{
- struct snd_cx18_card *cxsc = snd_kcontrol_chip(kctl);
- struct cx18 *cx = to_cx18(cxsc->v4l2_dev);
- struct v4l2_control vctrl;
- int ret;
-
- vctrl.id = V4L2_CID_AUDIO_VOLUME;
- vctrl.value = dB_to_cx18_av_vol(uctl->value.integer.value[0]);
-
- snd_cx18_lock(cxsc);
-
- /* Fetch current state */
- ret = v4l2_subdev_call(cx->sd_av, core, g_ctrl, &vctrl);
-
- if (ret ||
- (cx18_av_vol_to_dB(vctrl.value) != uctl->value.integer.value[0])) {
-
- /* Set, if needed */
- vctrl.value = dB_to_cx18_av_vol(uctl->value.integer.value[0]);
- ret = v4l2_subdev_call(cx->sd_av, core, s_ctrl, &vctrl);
- if (!ret)
- ret = 1; /* Indicate control was changed w/o error */
- }
- snd_cx18_unlock(cxsc);
-
- return ret;
-}
-
/* This is a bit of overkill, the slider is already in dB internally */
static DECLARE_TLV_DB_SCALE(snd_cx18_mixer_tv_vol_db_scale, -9600, 100, 0);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] audit: use supplied gfp_mask from audit_buffer in kauditd_send_multicast_skb
On Friday, December 19, 2014 07:52:59 PM valdis.kletni...@vt.edu wrote: > On Thu, 18 Dec 2014 23:09:27 -0500, Richard Guy Briggs said: > > Eric Paris explains: Since kauditd_send_multicast_skb() gets called in > > audit_log_end(), which can come from any context (aka even a sleeping > > context) GFP_KERNEL can't be used. Since the audit_buffer knows what > > context it should use, pass that down and use that. > > > > See: https://lkml.org/lkml/2014/12/16/542 > > > > Reported-by: Valdis Kletnieks > > Signed-off-by: Richard Guy Briggs > > --- > > > > kernel/audit.c |8 > > 1 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/kernel/audit.c b/kernel/audit.c > > index 7b83c55..ce484fb 100644 > > I was reliably triggering 3-4 BUGs an hour, and with this patch applied I've > gone 9 hours without seeing one. > > So feel free to add a Tested-By: when it goes out. Added, thanks for your help. -- paul moore security @ redhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] security: selinux: avc.c: Remove unused function
On Saturday, December 20, 2014 01:32:10 PM Rickard Strandqvist wrote:
> Remove the function avc_sidcmp() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> security/selinux/avc.c |5 -
> 1 file changed, 5 deletions(-)
Thanks, applied to the SELinux next branch with some minor changes to the
patch's subject line.
> diff --git a/security/selinux/avc.c b/security/selinux/avc.c
> index a18f1fa..afcc0ae 100644
> --- a/security/selinux/avc.c
> +++ b/security/selinux/avc.c
> @@ -517,11 +517,6 @@ out:
> return rc;
> }
>
> -static inline int avc_sidcmp(u32 x, u32 y)
> -{
> - return (x == y || x == SECSID_WILD || y == SECSID_WILD);
> -}
> -
> /**
> * avc_update_node Update an AVC entry
> * @event : Updating event
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sound: pci: hda: patch_analog.c: Remove unused function
Remove the function ad198x_ch_mode_get() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
sound/pci/hda/patch_analog.c |9 -
1 file changed, 9 deletions(-)
diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c
index 06275f8..9d5257b 100644
--- a/sound/pci/hda/patch_analog.c
+++ b/sound/pci/hda/patch_analog.c
@@ -707,15 +707,6 @@ static int ad198x_ch_mode_info(struct snd_kcontrol
*kcontrol,
spec->num_channel_mode);
}
-static int ad198x_ch_mode_get(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *ucontrol)
-{
- struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
- struct ad198x_spec *spec = codec->spec;
- return snd_hda_ch_mode_get(codec, ucontrol, spec->channel_mode,
- spec->num_channel_mode,
spec->multiout.max_channels);
-}
-
static int ad198x_ch_mode_put(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol)
{
--
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] usb: gadget: udc: s3c2410_udc.c: Remove some unused functions
Removes some functions that are not used anywhere:
s3c2410_udc_clear_ep_state() s3c2410_udc_set_ep0_sse_out()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/usb/gadget/udc/s3c2410_udc.c | 20
1 file changed, 20 deletions(-)
diff --git a/drivers/usb/gadget/udc/s3c2410_udc.c
b/drivers/usb/gadget/udc/s3c2410_udc.c
index ff423d1..41b60cd 100644
--- a/drivers/usb/gadget/udc/s3c2410_udc.c
+++ b/drivers/usb/gadget/udc/s3c2410_udc.c
@@ -238,14 +238,6 @@ static inline void s3c2410_udc_set_ep0_de_out(void __iomem
*base)
S3C2410_UDC_EP0_CSR_REG);
}
-static inline void s3c2410_udc_set_ep0_sse_out(void __iomem *base)
-{
- udc_writeb(base, S3C2410_UDC_INDEX_EP0, S3C2410_UDC_INDEX_REG);
- udc_writeb(base, (S3C2410_UDC_EP0_CSR_SOPKTRDY
- | S3C2410_UDC_EP0_CSR_SSE),
- S3C2410_UDC_EP0_CSR_REG);
-}
-
static inline void s3c2410_udc_set_ep0_de_in(void __iomem *base)
{
udc_writeb(base, S3C2410_UDC_INDEX_EP0, S3C2410_UDC_INDEX_REG);
@@ -291,18 +283,6 @@ static void s3c2410_udc_nuke(struct s3c2410_udc *udc,
}
}
-static inline void s3c2410_udc_clear_ep_state(struct s3c2410_udc *dev)
-{
- unsigned i;
-
- /* hardware SET_{CONFIGURATION,INTERFACE} automagic resets endpoint
-* fifos, and pending transactions mustn't be continued in any case.
-*/
-
- for (i = 1; i < S3C2410_ENDPOINTS; i++)
- s3c2410_udc_nuke(dev, &dev->ep[i], -ECONNABORTED);
-}
-
static inline int s3c2410_udc_fifo_count_out(void)
{
int tmp;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftracetest: Replace usleep with sleep 0.000001
On Sat, 20 Dec 2014 21:42:13 +0100 Pavel Machek wrote: > On Wed 2014-12-10 15:38:27, Michael Ellerman wrote: > > usleep is a Fedoraism, it's not generally available on Debian based > > systems AFAICS. > > > > GNU sleep accepts a floating point argument, so use that instead. > > > > Signed-off-by: Michael Ellerman > > Could ftrace user interface be enhanced not to need random delays? > Not sure what you are talking about. These "random delays" are not for the interface, but instead to force some events to happen and to make sure they did. As the subject states, this is for "ftracetest" which is the selftests for ftrace. The usleep is basically a "do something to trigger events", and we don't want to wait long in doing it. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] fbdev fixes for 3.19
On Sat 2014-12-20 22:20:27, Pavel Machek wrote: > On Sat 2014-12-20 22:01:25, Pavel Machek wrote: > > Hi! > > > > > Please pull fbdev changes for 3.19. > > > > > > Tomi > > > > v3.19-rc0 breaks video on my n900. > > > > > Archit Taneja (7): > > > OMAPDSS: DPI: Use DPI driver data > > > OMAPDSS: DPI: Allocate driver data > > > OMAPDSS: DPI: Store dpi_data pointer in the DT port's data > > > OMAPDSS: DSS: init dss ports cleanly > > > OMAPDSS: DT: Get source endpoint by matching reg-id > > > OMAPDSS: DPI: Add support for multiple instances > > > OMAPDSS: DSS: add a param to dpi_select_source which specifies > > > it's port number > > > > And I have these in my tree, so I should have latest fixes. Any ideas > > what I should try? > > I test-merged 3315764efceaccfb02c7d4c99ef8eed6716cd861, and boom, > video is gone. I reverted 4b4123f0c7b02f7cf1a3189f967f079197578c3a..9051909e451a0368c95ccf74562adb53fd2719f8 in 3.19, and voila, video is back. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] iio: ak8975: Make sure chipset is always initialized
I will have closer look on why acpi_match_device could fail. This patch was only based on code reading when trying to fix the compiler warning mentioned in the commit message. [Sorry for top posting] On Sat, Dec 20, 2014 at 11:29 PM, Pandruvada, Srinivas wrote: > +Mika > > On Sat, 2014-12-20 at 13:26 -0800, Srinivas Pandruvada wrote: >> On Sat, 2014-12-20 at 00:25 +0200, Daniel Baluta wrote: >> > On Sat, Dec 20, 2014 at 12:16 AM, Hartmut Knaack wrote: >> > > Daniel Baluta schrieb am 18.12.2014 um 18:16: >> > >> When using ACPI, if acpi_match_device fails then chipset enum will be >> > >> uninitialized and &ak_def_array[chipset] will point to some bad address. >> > >> >> I am missing something. You are enumerated over i2c device, which was >> created from ACPI PNP resource. There is a valid handle or and the >> device has an ACPI companion at the least. If this failing, I have to >> check the code for acpi i2c. >> Can you check why this check failed? We may have bug in i2c handling. >> >> Thanks, >> Srinivas >> >> > >> This fixes the following compilation warning: >> > >> >> > >> drivers/iio/magnetometer/ak8975.c: In function ‘ak8975_probe’: >> > >> drivers/iio/magnetometer/ak8975.c:788:14: warning: ‘chipset’ may be used >> > >> uninitialized in this function [-Wmaybe-uninitialized] >> > >> data->def =ak_def_array[chipset]; >> > >> >> > >> Reported-by: Octavian Purdila >> > >> Signed-off-by: Daniel Baluta >> > >> --- >> > >> This is a RFC because while I'm pretty sure that chipset should be >> > >> initialized >> > >> with AK_MAX_TYPE in ak8975_match_acpi_device, I am not sure if we can >> > >> live with >> > >> a NULL return value of ak8975_match_acpi_device. Current implementation >> > >> ignores >> > >> return value of ak8975_match_acpi_device. >> > > This seems to be the actual problem: these _match_acpi_device functions >> > > return >> > > NULL on failure, and this should be checked for. >> > >> > Ok, so this would acceptable? >> > >> > diff --git a/drivers/iio/magnetometer/ak8975.c >> > b/drivers/iio/magnetometer/ak8975.c >> > index 0d10a4b..68d99e9 100644 >> > --- a/drivers/iio/magnetometer/ak8975.c >> > +++ b/drivers/iio/magnetometer/ak8975.c >> > @@ -776,8 +776,9 @@ static int ak8975_probe(struct i2c_client *client, >> > name = id->name; >> > } else if (ACPI_HANDLE(&client->dev)) >> > name = ak8975_match_acpi_device(&client->dev, &chipset); >> > - else >> > - return -ENOSYS; >> > + >> > + if (!name) >> > + return -ENODEV; >> > >> > >> > I still have some doubts about return code in case of error. >> > >> > For ak8975 we use -ENOSYS, but for kxcjk-1013 we use -ENODEV. >> > >> > I will send a patch after we clear this out. >> > >> > thanks, >> > Daniel. >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] iio: ak8975: Make sure chipset is always initialized
+Mika
On Sat, 2014-12-20 at 13:26 -0800, Srinivas Pandruvada wrote:
> On Sat, 2014-12-20 at 00:25 +0200, Daniel Baluta wrote:
> > On Sat, Dec 20, 2014 at 12:16 AM, Hartmut Knaack wrote:
> > > Daniel Baluta schrieb am 18.12.2014 um 18:16:
> > >> When using ACPI, if acpi_match_device fails then chipset enum will be
> > >> uninitialized and &ak_def_array[chipset] will point to some bad address.
> > >>
> I am missing something. You are enumerated over i2c device, which was
> created from ACPI PNP resource. There is a valid handle or and the
> device has an ACPI companion at the least. If this failing, I have to
> check the code for acpi i2c.
> Can you check why this check failed? We may have bug in i2c handling.
>
> Thanks,
> Srinivas
>
> > >> This fixes the following compilation warning:
> > >>
> > >> drivers/iio/magnetometer/ak8975.c: In function ‘ak8975_probe’:
> > >> drivers/iio/magnetometer/ak8975.c:788:14: warning: ‘chipset’ may be used
> > >> uninitialized in this function [-Wmaybe-uninitialized]
> > >> data->def =ak_def_array[chipset];
> > >>
> > >> Reported-by: Octavian Purdila
> > >> Signed-off-by: Daniel Baluta
> > >> ---
> > >> This is a RFC because while I'm pretty sure that chipset should be
> > >> initialized
> > >> with AK_MAX_TYPE in ak8975_match_acpi_device, I am not sure if we can
> > >> live with
> > >> a NULL return value of ak8975_match_acpi_device. Current implementation
> > >> ignores
> > >> return value of ak8975_match_acpi_device.
> > > This seems to be the actual problem: these _match_acpi_device functions
> > > return
> > > NULL on failure, and this should be checked for.
> >
> > Ok, so this would acceptable?
> >
> > diff --git a/drivers/iio/magnetometer/ak8975.c
> > b/drivers/iio/magnetometer/ak8975.c
> > index 0d10a4b..68d99e9 100644
> > --- a/drivers/iio/magnetometer/ak8975.c
> > +++ b/drivers/iio/magnetometer/ak8975.c
> > @@ -776,8 +776,9 @@ static int ak8975_probe(struct i2c_client *client,
> > name = id->name;
> > } else if (ACPI_HANDLE(&client->dev))
> > name = ak8975_match_acpi_device(&client->dev, &chipset);
> > - else
> > - return -ENOSYS;
> > +
> > + if (!name)
> > + return -ENODEV;
> >
> >
> > I still have some doubts about return code in case of error.
> >
> > For ak8975 we use -ENOSYS, but for kxcjk-1013 we use -ENODEV.
> >
> > I will send a patch after we clear this out.
> >
> > thanks,
> > Daniel.
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [RFC PATCH] iio: ak8975: Make sure chipset is always initialized
On Sat, 2014-12-20 at 00:25 +0200, Daniel Baluta wrote: > On Sat, Dec 20, 2014 at 12:16 AM, Hartmut Knaack wrote: > > Daniel Baluta schrieb am 18.12.2014 um 18:16: > >> When using ACPI, if acpi_match_device fails then chipset enum will be > >> uninitialized and &ak_def_array[chipset] will point to some bad address. > >> I am missing something. You are enumerated over i2c device, which was created from ACPI PNP resource. There is a valid handle or and the device has an ACPI companion at the least. If this failing, I have to check the code for acpi i2c. Can you check why this check failed? We may have bug in i2c handling. Thanks, Srinivas > >> This fixes the following compilation warning: > >> > >> drivers/iio/magnetometer/ak8975.c: In function ‘ak8975_probe’: > >> drivers/iio/magnetometer/ak8975.c:788:14: warning: ‘chipset’ may be used > >> uninitialized in this function [-Wmaybe-uninitialized] > >> data->def =ak_def_array[chipset]; > >> > >> Reported-by: Octavian Purdila > >> Signed-off-by: Daniel Baluta > >> --- > >> This is a RFC because while I'm pretty sure that chipset should be > >> initialized > >> with AK_MAX_TYPE in ak8975_match_acpi_device, I am not sure if we can live > >> with > >> a NULL return value of ak8975_match_acpi_device. Current implementation > >> ignores > >> return value of ak8975_match_acpi_device. > > This seems to be the actual problem: these _match_acpi_device functions > > return > > NULL on failure, and this should be checked for. > > Ok, so this would acceptable? > > diff --git a/drivers/iio/magnetometer/ak8975.c > b/drivers/iio/magnetometer/ak8975.c > index 0d10a4b..68d99e9 100644 > --- a/drivers/iio/magnetometer/ak8975.c > +++ b/drivers/iio/magnetometer/ak8975.c > @@ -776,8 +776,9 @@ static int ak8975_probe(struct i2c_client *client, > name = id->name; > } else if (ACPI_HANDLE(&client->dev)) > name = ak8975_match_acpi_device(&client->dev, &chipset); > - else > - return -ENOSYS; > + > + if (!name) > + return -ENODEV; > > > I still have some doubts about return code in case of error. > > For ak8975 we use -ENOSYS, but for kxcjk-1013 we use -ENODEV. > > I will send a patch after we clear this out. > > thanks, > Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init
On Sat, Dec 20, 2014 at 10:46:12PM +0200, Oded Gabbay wrote: > When amdkfd and radeon are compiled inside the kernel image (not as modules), > radeon will load before amdkfd and will set *kfd2kgd to its interface > structure. Therefore, we must not set *kfd2kgd to NULL when amdkfd is loaded > because it will override radeon's initialization and cause kernel BUG. > > Signed-off-by: Oded Gabbay > --- > drivers/gpu/drm/amd/amdkfd/kfd_module.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c > b/drivers/gpu/drm/amd/amdkfd/kfd_module.c > index 95d5af1..236562f 100644 > --- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c > @@ -34,7 +34,7 @@ > #define KFD_DRIVER_MINOR 7 > #define KFD_DRIVER_PATCHLEVEL0 > > -const struct kfd2kgd_calls *kfd2kgd; > +const struct kfd2kgd_calls *kfd2kgd = NULL; This change does nothing, that is what the original code did already. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] fbdev fixes for 3.19
On Sat 2014-12-20 22:01:25, Pavel Machek wrote: > Hi! > > > Please pull fbdev changes for 3.19. > > > > Tomi > > v3.19-rc0 breaks video on my n900. > > > Archit Taneja (7): > > OMAPDSS: DPI: Use DPI driver data > > OMAPDSS: DPI: Allocate driver data > > OMAPDSS: DPI: Store dpi_data pointer in the DT port's data > > OMAPDSS: DSS: init dss ports cleanly > > OMAPDSS: DT: Get source endpoint by matching reg-id > > OMAPDSS: DPI: Add support for multiple instances > > OMAPDSS: DSS: add a param to dpi_select_source which specifies > > it's port number > > And I have these in my tree, so I should have latest fixes. Any ideas > what I should try? I test-merged 3315764efceaccfb02c7d4c99ef8eed6716cd861, and boom, video is gone. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sat, Dec 20, 2014 at 10:25 AM, Linus Torvalds wrote: > > How/where is the HPET overflow case handled? I don't know the code enough. Hmm, ok, I've re-acquainted myself with it. And I have to admit that I can't see anything wrong. The whole "update_wall_clock" and the shadow timekeeping state is confusing as hell, but seems fine. We'd have to avoid update_wall_clock for a *long* time for overflows to occur. And the overflow in 32 bits isn't that special, since the only thing that really matters is the overflow of "cycle_now - tkr->cycle_last" within the mask. So I'm not seeing anything even halfway suspicious. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] x86_64, vdso: Fix the vdso address randomization algorithm
On Sat, Dec 20, 2014 at 9:40 AM, Andy Lutomirski wrote:
> The theory behind vdso randomization is that it's mapped at a random
> offset above the top of the stack. To avoid wasting a page of
> memory for an extra page table, the vdso isn't supposed to extend
> past the lowest PMD into which it can fit. Other than that, the
> address should be a uniformly distributed address that meets all of
> the alignment requirements.
>
> The current algorithm is buggy: the vdso has about a 50% probability
> of being at the very end of a PMD. The current algorithm also has a
> decent chance of failing outright due to incorrect handling of the
> case where the top of the stack is near the top of its PMD.
>
> This fixes the implementation. The paxtest estimate of vdso
> "randomisation" improves from 11 bits to 18 bits. (Disclaimer: I
> don't know what the paxtest code is actually calculating.)
>
> It's worth noting that this algorithm is inherently biased: the vdso
> is more likely to end up near the end of its PMD than near the
> beginning. Ideally we would either nix the PMD sharing requirement
> or jointly randomize the vdso and the stack to reduce the bias.
>
> In the mean time, this is a considerable improvement with basically
> no risk of compatibility issues, since the allowed outputs of the
> algorithm are unchanged.
>
> As an easy test, doing this:
>
> for i in `seq 1`
> do grep -P vdso /proc/self/maps |cut -d- -f1
> done |sort |uniq -d
>
> used to produce lots of output (1445 lines on my most recent run).
> A tiny subset looks like this:
>
> 7fffdfffe000
> 7fffe01fe000
> 7fffe05fe000
> 7fffe07fe000
> 7fffe09fe000
> 7fffe0bfe000
> 7fffe0dfe000
>
> Note the suspicious fe000 endings. With the fix, I get a much more
> palatable 76 repeated addresses.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andy Lutomirski
Thanks for fixing this! :)
Reviewed-by: Kees Cook
-Kees
> ---
> arch/x86/vdso/vma.c | 45 +
> 1 file changed, 29 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c
> index 009495b9ab4b..1c9f750c3859 100644
> --- a/arch/x86/vdso/vma.c
> +++ b/arch/x86/vdso/vma.c
> @@ -41,12 +41,17 @@ void __init init_vdso_image(const struct vdso_image
> *image)
>
> struct linux_binprm;
>
> -/* Put the vdso above the (randomized) stack with another randomized offset.
> - This way there is no hole in the middle of address space.
> - To save memory make sure it is still in the same PTE as the stack top.
> - This doesn't give that many random bits.
> -
> - Only used for the 64-bit and x32 vdsos. */
> +/*
> + * Put the vdso above the (randomized) stack with another randomized
> + * offset. This way there is no hole in the middle of address space.
> + * To save memory make sure it is still in the same PTE as the stack
> + * top. This doesn't give that many random bits.
> + *
> + * Note that this algorithm is imperfect: the distribution of the vdso
> + * start address within a PMD is biased toward the end.
> + *
> + * Only used for the 64-bit and x32 vdsos.
> + */
> static unsigned long vdso_addr(unsigned long start, unsigned len)
> {
> #ifdef CONFIG_X86_32
> @@ -54,22 +59,30 @@ static unsigned long vdso_addr(unsigned long start,
> unsigned len)
> #else
> unsigned long addr, end;
> unsigned offset;
> - end = (start + PMD_SIZE - 1) & PMD_MASK;
> +
> + /*
> +* Round up the start address. It can start out unaligned as a result
> +* of stack start randomization.
> +*/
> + start = PAGE_ALIGN(start);
> +
> + /* Round the lowest possible end address up to a PMD boundary. */
> + end = (start + len + PMD_SIZE - 1) & PMD_MASK;
> if (end >= TASK_SIZE_MAX)
> end = TASK_SIZE_MAX;
> end -= len;
> - /* This loses some more bits than a modulo, but is cheaper */
> - offset = get_random_int() & (PTRS_PER_PTE - 1);
> - addr = start + (offset << PAGE_SHIFT);
> - if (addr >= end)
> - addr = end;
> +
> + if (end > start) {
> + offset = get_random_int() % (((end - start) >> PAGE_SHIFT) +
> 1);
> + addr = start + (offset << PAGE_SHIFT);
> + } else {
> + addr = start;
> + }
>
> /*
> -* page-align it here so that get_unmapped_area doesn't
> -* align it wrongfully again to the next page. addr can come in 4K
> -* unaligned here as a result of stack start randomization.
> +* Forcibly align the final address in case we have a hardware
> +* issue that requires alignment for performance reasons.
> */
> - addr = PAGE_ALIGN(addr);
> addr = align_vdso_addr(addr);
>
> return addr;
> --
> 2.1.0
>
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
[PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init
When amdkfd and radeon are compiled inside the kernel image (not as modules),
radeon will load before amdkfd and will set *kfd2kgd to its interface
structure. Therefore, we must not set *kfd2kgd to NULL when amdkfd is loaded
because it will override radeon's initialization and cause kernel BUG.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_module.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
index 95d5af1..236562f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
@@ -34,7 +34,7 @@
#define KFD_DRIVER_MINOR 7
#define KFD_DRIVER_PATCHLEVEL 0
-const struct kfd2kgd_calls *kfd2kgd;
+const struct kfd2kgd_calls *kfd2kgd = NULL;
static const struct kgd2kfd_calls kgd2kfd = {
.exit = kgd2kfd_exit,
.probe = kgd2kfd_probe,
@@ -84,14 +84,13 @@ EXPORT_SYMBOL(kgd2kfd_init);
void kgd2kfd_exit(void)
{
+ kfd2kgd = NULL;
}
static int __init kfd_module_init(void)
{
int err;
- kfd2kgd = NULL;
-
/* Verify module parameters */
if ((sched_policy < KFD_SCHED_POLICY_HWS) ||
(sched_policy > KFD_SCHED_POLICY_NO_HWS)) {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] fbdev fixes for 3.19
Hi! > Please pull fbdev changes for 3.19. > > Tomi v3.19-rc0 breaks video on my n900. > Archit Taneja (7): > OMAPDSS: DPI: Use DPI driver data > OMAPDSS: DPI: Allocate driver data > OMAPDSS: DPI: Store dpi_data pointer in the DT port's data > OMAPDSS: DSS: init dss ports cleanly > OMAPDSS: DT: Get source endpoint by matching reg-id > OMAPDSS: DPI: Add support for multiple instances > OMAPDSS: DSS: add a param to dpi_select_source which specifies > it's port number And I have these in my tree, so I should have latest fixes. Any ideas what I should try? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: add check for keyword 'boolean' in Kconfig definitions
(adding Andrew Morton)
On Sat, 2014-12-20 at 15:40 -0500, Christoph Jaeger wrote:
> Discourage the use of keyword 'boolean' for type definition attributes of
> config options as support for it will be dropped later on.
>
> Reference: http://lkml.kernel.org/r/cover.1418003065.git...@linux.com
> Suggested-by: Daniel Borkmann
> Signed-off-by: Christoph Jaeger
Seems sensible.
> ---
> scripts/checkpatch.pl | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index f0bb6d6..cae974e 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2355,6 +2355,13 @@ sub process {
>"Use of CONFIG_EXPERIMENTAL is deprecated. For
> alternatives, see https://lkml.org/lkml/2012/10/23/580\n";);
> }
>
> +# discourage the use of boolean for type definition attributes of Kconfig
> options
> + if ($realfile =~ /Kconfig/ &&
> + $line =~ /^\+\s*\bboolean\b/) {
> + WARN("CONFIG_TYPE_BOOLEAN",
> + "Use of boolean is deprecated, please use bool
> instead.\n" . $herecurr);
> + }
> +
> if (($realfile =~ /Makefile.*/ || $realfile =~ /Kbuild.*/) &&
> ($line =~ /\+(EXTRA_[A-Z]+FLAGS).*/)) {
> my $flag = $1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] amdkfd: Track when amdkfd init is complete
This patch adds a new function to amdkfd, which returns 1 if the amdkfd
initialization function has completed, and 0 otherwise.
This is necessary for the case when amdkfd and radeon are both compiled inside
the kernel image (not as modules). In that case, radeon probes the existing GPU
before amdkfd is even loaded. When radeon encounters an AMD GPU, it will pass
that information to amdkfd. However, if amdkfd is not loaded than that call
will fail and when amdkfd is eventually loaded, it won't know about that GPU.
Even if that call is delayed to a later stage, we will still need to know
whether amdkfd has already been initialized.
Note that when the two modules are compiled as modules, this situation can't
occur as the kernel enforces the order of loading.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_module.c | 9 +
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
index 236562f..848ebed 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
@@ -60,6 +60,13 @@ module_param(max_num_of_queues_per_process, int, 0444);
MODULE_PARM_DESC(max_num_of_queues_per_process,
"Kernel cmdline parameter that defines the amdkfd maximum number of
supported queues per process");
+static int amdkfd_init_completed;
+
+int amdkfd_is_init_completed(void)
+{
+ return amdkfd_init_completed;
+}
+
bool kgd2kfd_init(unsigned interface_version,
const struct kfd2kgd_calls *f2g,
const struct kgd2kfd_calls **g2f)
@@ -128,6 +135,8 @@ static int __init kfd_module_init(void)
dev_info(kfd_device, "Initialized module\n");
+ amdkfd_init_completed = 1;
+
return 0;
err_topology:
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index f9fb81e..01df7e6 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -153,6 +153,8 @@ struct kfd_dev {
bool interrupts_active;
};
+int amdkfd_is_init_completed(void);
+
/* KGD2KFD callbacks */
void kgd2kfd_exit(void);
struct kfd_dev *kgd2kfd_probe(struct kgd_dev *kgd, struct pci_dev *pdev);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] amdkfd: Use workqueue for GPU init
When amd_iommu_v2, amdkfd and radeon are all compiled inside the kernel image
(not as modules), radeon probes the existing GPU before amdkfd and amd_iommu_v2
are even loaded. When radeon encounters an AMD GPU, it will pass that
information to amdkfd. However, that call will fail and will cause a kernel BUG.
We could poll in radeon on when amdkfd and amd_iommu_v2 have been loaded, but
that would stall radeon.
Therefore, this patch moves the amdkfd part of GPU initialization to a
workqueue. When radeon calls amdkfd to perform GPU related initialization, it
will check if both amdkfd and amd_iommu_v2 have been loaded. If so, which is
the situation when the three drivers are compiled as modules, it will call the
relevant amdkfd function directly. If not, it will queue the initialization
work on the workqueue. The work function will schedule itself until both amdkfd
and amd_iommu_v2 have been loaded. Then, it will call the relevant amdkfd
function.
The workqueue is defined per kfd_dev structure (per GPU).
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 72 +++--
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 +
2 files changed, 70 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 43884eb..cec5b4b 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "kfd_priv.h"
#include "kfd_device_queue_manager.h"
@@ -40,6 +41,11 @@ struct kfd_deviceid {
const struct kfd_device_info *device_info;
};
+struct kfd_device_init_work {
+ struct work_struct kfd_work;
+ struct kfd_dev *dev;
+};
+
/* Please keep this sorted by increasing device id. */
static const struct kfd_deviceid supported_devices[] = {
{ 0x1304, &kaveri_device_info },/* Kaveri */
@@ -99,6 +105,8 @@ struct kfd_dev *kgd2kfd_probe(struct kgd_dev *kgd, struct
pci_dev *pdev)
kfd->pdev = pdev;
kfd->init_complete = false;
+ kfd->kfd_dev_wq = create_workqueue("kfd_dev_wq");
+
return kfd;
}
@@ -161,13 +169,10 @@ static void iommu_pasid_shutdown_callback(struct pci_dev
*pdev, int pasid)
kfd_unbind_process_from_device(dev, pasid);
}
-bool kgd2kfd_device_init(struct kfd_dev *kfd,
-const struct kgd2kfd_shared_resources *gpu_resources)
+static bool kfd_kgd_device_init(struct kfd_dev *kfd)
{
unsigned int size;
- kfd->shared_resources = *gpu_resources;
-
/* calculate max size of mqds needed for queues */
size = max_num_of_processes *
max_num_of_queues_per_process *
@@ -249,6 +254,63 @@ out:
return kfd->init_complete;
}
+static void kfd_device_wq_init_device(struct work_struct *work)
+{
+ struct kfd_device_init_work *my_work;
+ struct kfd_dev *kfd;
+
+ my_work = (struct kfd_device_init_work *) work;
+
+ kfd = my_work->dev;
+
+ /*
+* As long as amdkfd or amd_iommu_v2 are not initialized, we
+* yield the processor
+*/
+ while ((!amdkfd_is_init_completed()) ||
+ (!amd_iommu_v2_is_init_completed()))
+ schedule();
+
+ kfd_kgd_device_init(kfd);
+}
+
+bool kgd2kfd_device_init(struct kfd_dev *kfd,
+const struct kgd2kfd_shared_resources *gpu_resources)
+{
+ struct kfd_device_init_work *work;
+
+ kfd->shared_resources = *gpu_resources;
+
+ /*
+* When amd_iommu_v2, amdkfd and radeon are compiled inside the kernel,
+* there is no mechanism to enforce order of loading between the
+* drivers. Therefore, we need to use an explicit form of
+* synchronization to know when amdkfd and amd_iommu_v2 have finished
+* there initialization routines
+*/
+ if ((!amdkfd_is_init_completed()) ||
+ (!amd_iommu_v2_is_init_completed())) {
+ BUG_ON(!kfd->kfd_dev_wq);
+
+ work = (struct kfd_device_init_work *)
+ kmalloc(sizeof(struct kfd_device_init_work),
+ GFP_ATOMIC);
+
+ if (!work) {
+ pr_err("kfd: no memory for device work queue\n");
+ return false;
+ }
+
+ INIT_WORK((struct work_struct *) work,
+ kfd_device_wq_init_device);
+ work->dev = kfd;
+ queue_work(kfd->kfd_dev_wq, (struct work_struct *) work);
+ return true;
+ }
+
+ return kfd_kgd_device_init(kfd);
+}
+
void kgd2kfd_device_exit(struct kfd_dev *kfd)
{
if (kfd->init_complete) {
@@ -258,6 +320,8 @@ void kgd2kfd_device_exit(struct kfd_dev *kfd)
kfd_topology_remove_device(kfd);
}
+ flush_workqueue(kfd->kfd_dev_wq);
+ destroy_workq
[PATCH 0/3] Use workqueue for device init in amdkfd
This small patch-set, together with amd_iommu_v2 patch at http://lists.linuxfoundation.org/pipermail/iommu/2014-December/011435.html was created to solve the bug described at https://bugzilla.kernel.org/show_bug.cgi?id=89661 (Kernel panic when trying use amdkfd driver on Kaveri). That bug appears only when radeon, amdkfd and amd_iommu_v2 are compiled inside the kernel (not as modules). In that case, the correct loading order, as determined by the exported symbol used by each driver, is not enforced anymore and the kernel loads them based on who was linked first. That makes radeon load first, amdkfd second and amd_iommu_v2 third. Because the initialization of a device in amdkfd is initiated by radeon, and can only be completed if amdkfd and amd_iommu_v2 were loaded and initialized, then in the case mentioned above, this initalization fails and there is a kernel panic as some pointers are not initialized but used nontheless. To solve this problem, amdkfd now checks if both it and amd_iommu_v2 were loaded before trying to initalize the device. If not, it enqueue the work using a workqueue, which allows radeon to continue its device initialization (because radeon calls amdkfd to initalize the device). The work function schedules itself as long as amdkfd and amd_iommu_v2 were not initialized. Detection of when the modules finished their initialization is done by a simple variable that is initialized to 1 when the module_init function is completed successfully. Other methods for detection were checked, e.g. module_is_live() and MODULE_SOFTDEP(), but they were proved not to work when all modules are compiled in the kernel image (which is the problematic scenario to begin with). Oded Oded Gabbay (3): amdkfd: Don't clear *kfd2kgd on kfd_module_init amdkfd: Track when amdkfd init is complete amdkfd: Use workqueue for GPU init drivers/gpu/drm/amd/amdkfd/kfd_device.c | 72 +++-- drivers/gpu/drm/amd/amdkfd/kfd_module.c | 14 +-- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 4 ++ 3 files changed, 83 insertions(+), 7 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth: Add hci_h4p driver
Pavel, On Sat, 2014-12-20 at 21:23 +0100, Pavel Machek wrote: > --- a/drivers/bluetooth/Kconfig > +++ b/drivers/bluetooth/Kconfig > @@ -243,4 +243,13 @@ config BT_WILINK > Say Y here to compile support for Texas Instrument's WiLink7 driver > into the kernel or say M to compile it as module (btwilink). > > +config BT_NOKIA_H4P > + tristate "HCI driver with H4 Nokia extensions" > + help > + Bluetooth HCI driver with H4 extensions. This driver provides > + support for H4+ Bluetooth chip with vendor-specific H4 extensions. > + > + Say Y here to compile support for h4 extended devices into the kernel > + or say M to compile it as module (btnokia_h4p). Will this module be called btnokia_h4p or ... > + > endmenu > diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile > index 9fe8a87..624ef3fc 100644 > --- a/drivers/bluetooth/Makefile > +++ b/drivers/bluetooth/Makefile > @@ -31,4 +31,7 @@ hci_uart-$(CONFIG_BT_HCIUART_ATH3K) += hci_ath.o > hci_uart-$(CONFIG_BT_HCIUART_3WIRE) += hci_h5.o > hci_uart-objs:= $(hci_uart-y) > > +obj-$(CONFIG_BT_NOKIA_H4P) += nokia_h4p.o ... nokia_h4p? > +nokia_h4p-objs := nokia_core.o nokia_fw.o nokia_uart.o > + > ccflags-y += -D__CHECK_ENDIAN__ Or did I miss some make magic here? Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftracetest: Replace usleep with sleep 0.000001
On Wed 2014-12-10 15:38:27, Michael Ellerman wrote:
> usleep is a Fedoraism, it's not generally available on Debian based
> systems AFAICS.
>
> GNU sleep accepts a floating point argument, so use that instead.
>
> Signed-off-by: Michael Ellerman
Could ftrace user interface be enhanced not to need random delays?
Pavel
> ---
> tools/testing/selftests/ftrace/test.d/event/event-enable.tc | 6 +++---
> tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
> b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
> index 668616d9bb03..c5343add3407 100644
> --- a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
> +++ b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
> @@ -21,7 +21,7 @@ reset_tracer
> do_reset
>
> echo 'sched:sched_switch' > set_event
> -usleep 1
> +sleep 0.01
>
> count=`cat trace | grep sched_switch | wc -l`
> if [ $count -eq 0 ]; then
> @@ -31,7 +31,7 @@ fi
> do_reset
>
> echo 1 > events/sched/sched_switch/enable
> -usleep 1
> +sleep 0.01
>
> count=`cat trace | grep sched_switch | wc -l`
> if [ $count -eq 0 ]; then
> @@ -41,7 +41,7 @@ fi
> do_reset
>
> echo 0 > events/sched/sched_switch/enable
> -usleep 1
> +sleep 0.01
>
> count=`cat trace | grep sched_switch | wc -l`
> if [ $count -ne 0 ]; then
> diff --git a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
> b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
> index 655c415b6e7f..84a2020d4e7b 100644
> --- a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
> +++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
> @@ -21,7 +21,7 @@ reset_tracer
> do_reset
>
> echo 'sched:*' > set_event
> -usleep 1
> +sleep 0.01
>
> count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
> if [ $count -lt 3 ]; then
> @@ -31,7 +31,7 @@ fi
> do_reset
>
> echo 1 > events/sched/enable
> -usleep 1
> +sleep 0.01
>
> count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
> if [ $count -lt 3 ]; then
> @@ -41,7 +41,7 @@ fi
> do_reset
>
> echo 0 > events/sched/enable
> -usleep 1
> +sleep 0.01
>
> count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l`
> if [ $count -ne 0 ]; then
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] lustre: ptlrpc: add "ptlrpc_internal.h" to sec_gc.c
ptlrpc_internal.h contains the prototypes for sptlrpc_gc_init() and sptlrpc_gc_fini(), which are defined in sec_gc.c. This removes the following sparse warnings: drivers/staging/lustre/lustre/ptlrpc/sec_gc.c:217:5: warning: symbol 'sptlrpc_gc_init' was not declared. Should it be static? drivers/staging/lustre/lustre/ptlrpc/sec_gc.c:241:6: warning: symbol 'sptlrpc_gc_fini' was not declared. Should it be static? Signed-off-by: Spencer Baugh --- drivers/staging/lustre/lustre/ptlrpc/sec_gc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/lustre/lustre/ptlrpc/sec_gc.c b/drivers/staging/lustre/lustre/ptlrpc/sec_gc.c index c500aff..81de68e 100644 --- a/drivers/staging/lustre/lustre/ptlrpc/sec_gc.c +++ b/drivers/staging/lustre/lustre/ptlrpc/sec_gc.c @@ -47,6 +47,8 @@ #include "../include/lustre_net.h" #include "../include/lustre_sec.h" +#include "ptlrpc_internal.h" + #define SEC_GC_INTERVAL (30 * 60) -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kconfig: use bool instead of boolean for type definition attributes
Support for keyword 'boolean' will be dropped later on. No functional change. Reference: http://lkml.kernel.org/r/cover.1418003065.git...@linux.com Signed-off-by: Christoph Jaeger --- arch/mips/pmcs-msp71xx/Kconfig | 6 +++--- drivers/connector/Kconfig | 2 +- drivers/hwmon/Kconfig | 2 +- drivers/hwmon/pmbus/Kconfig | 2 +- drivers/i2c/Kconfig | 4 ++-- drivers/iio/Kconfig | 4 ++-- drivers/isdn/hardware/mISDN/Kconfig | 2 +- drivers/md/Kconfig | 4 ++-- drivers/md/persistent-data/Kconfig | 2 +- drivers/net/ethernet/ti/Kconfig | 4 ++-- drivers/net/usb/Kconfig | 12 ++-- drivers/net/wireless/rt2x00/Kconfig | 6 +++--- drivers/pci/pcie/aer/Kconfig| 2 +- drivers/rtc/Kconfig | 8 drivers/spi/Kconfig | 6 +++--- drivers/staging/board/Kconfig | 2 +- drivers/staging/emxx_udc/Kconfig| 2 +- drivers/staging/iio/Kconfig | 4 ++-- drivers/tty/serial/Kconfig | 2 +- drivers/usb/gadget/Kconfig | 34 +- drivers/usb/gadget/legacy/Kconfig | 2 +- drivers/usb/gadget/udc/Kconfig | 4 ++-- drivers/usb/phy/Kconfig | 2 +- init/Kconfig| 4 ++-- lib/Kconfig | 30 +++--- mm/Kconfig | 22 +++--- net/Kconfig | 14 +++--- net/sched/Kconfig | 2 +- net/switchdev/Kconfig | 2 +- security/integrity/Kconfig | 4 ++-- security/integrity/evm/Kconfig | 2 +- 31 files changed, 99 insertions(+), 99 deletions(-) diff --git a/arch/mips/pmcs-msp71xx/Kconfig b/arch/mips/pmcs-msp71xx/Kconfig index 6073ca4..4190093 100644 --- a/arch/mips/pmcs-msp71xx/Kconfig +++ b/arch/mips/pmcs-msp71xx/Kconfig @@ -36,14 +36,14 @@ config PMC_MSP7120_FPGA endchoice config MSP_HAS_USB - boolean + bool depends on PMC_MSP config MSP_ETH - boolean + bool select MSP_HAS_MAC depends on PMC_MSP config MSP_HAS_MAC - boolean + bool depends on PMC_MSP diff --git a/drivers/connector/Kconfig b/drivers/connector/Kconfig index 6e6730f..3de5f3a 100644 --- a/drivers/connector/Kconfig +++ b/drivers/connector/Kconfig @@ -12,7 +12,7 @@ menuconfig CONNECTOR if CONNECTOR config PROC_EVENTS - boolean "Report process events to userspace" + bool "Report process events to userspace" depends on CONNECTOR=y default y ---help--- diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 6529c09..33149a4 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -1595,7 +1595,7 @@ config SENSORS_W83795 will be called w83795. config SENSORS_W83795_FANCTRL - boolean "Include automatic fan control support (DANGEROUS)" + bool "Include automatic fan control support (DANGEROUS)" depends on SENSORS_W83795 default n help diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig index a674cd8..9f7dbd1 100644 --- a/drivers/hwmon/pmbus/Kconfig +++ b/drivers/hwmon/pmbus/Kconfig @@ -57,7 +57,7 @@ config SENSORS_LTC2978 be called ltc2978. config SENSORS_LTC2978_REGULATOR - boolean "Regulator support for LTC2978 and compatibles" + bool "Regulator support for LTC2978 and compatibles" depends on SENSORS_LTC2978 && REGULATOR help If you say yes here you get regulator support for Linear diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 8c9e619..78fbee4 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -35,11 +35,11 @@ config ACPI_I2C_OPREGION if I2C config I2C_BOARDINFO - boolean + bool default y config I2C_COMPAT - boolean "Enable compatibility bits for old user-space" + bool "Enable compatibility bits for old user-space" default y help Say Y here if you intend to run lm-sensors 3.1.1 or older, or any diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig index 345395e..397c8df 100644 --- a/drivers/iio/Kconfig +++ b/drivers/iio/Kconfig @@ -21,7 +21,7 @@ config IIO_BUFFER if IIO_BUFFER config IIO_BUFFER_CB -boolean "IIO callback buffer used for push in-kernel interfaces" + bool "IIO callback buffer used for push in-kernel interfaces" help Should be selected by any drivers that do in-kernel push usage. That is, those where the data is pushed to the consumer. @@ -44,7 +44,7 @@ config IIO_TRIGGERED_BUFFER endif # IIO_BUFFER config IIO_TRIGGER - boolean "Enable triggered sampling support" + bool "Enable triggered sampling support" help Provides IIO core support for triggers. Currently these are used to initialize capture of samples to push in
[PATCH] checkpatch: add check for keyword 'boolean' in Kconfig definitions
Discourage the use of keyword 'boolean' for type definition attributes of
config options as support for it will be dropped later on.
Reference: http://lkml.kernel.org/r/cover.1418003065.git...@linux.com
Suggested-by: Daniel Borkmann
Signed-off-by: Christoph Jaeger
---
scripts/checkpatch.pl | 7 +++
1 file changed, 7 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f0bb6d6..cae974e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2355,6 +2355,13 @@ sub process {
"Use of CONFIG_EXPERIMENTAL is deprecated. For
alternatives, see https://lkml.org/lkml/2012/10/23/580\n";);
}
+# discourage the use of boolean for type definition attributes of Kconfig
options
+ if ($realfile =~ /Kconfig/ &&
+ $line =~ /^\+\s*\bboolean\b/) {
+ WARN("CONFIG_TYPE_BOOLEAN",
+"Use of boolean is deprecated, please use bool
instead.\n" . $herecurr);
+ }
+
if (($realfile =~ /Makefile.*/ || $realfile =~ /Kbuild.*/) &&
($line =~ /\+(EXTRA_[A-Z]+FLAGS).*/)) {
my $flag = $1;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iommu/amd: Track when amd_iommu_v2 init is complete
On 12/20/2014 10:12 PM, Oded Gabbay wrote:
> This patch adds a new exported function to amd_iommu_v2, which returns 1 if
> the
> amd_iommu_v2 initialization function has completed, and 0 otherwise.
>
> This is necessary for the case when amd_iommu_v2 is compiled inside the kernel
> image (not as module) and another module (e.g. amdkfd), which is also compiled
> inside the kernel image, is dependent on amd_iommu_v2 functionality.
>
> In that case, there is no mechanism in the kernel that enforces the order of
> loading between the two modules. Therefore, If the amd_iommu_v2 is loaded
> _after_ the other module, and the other module calls one of
> amd_iommu_v2 exported functions _before_ amd_iommu_v2 is loaded, than that
> function will fail, and as a result, the calling module may fail as well.
>
> Note that when the two modules are compiled as modules, this situation can't
> occur as the kernel enforces the order of loading.
>
> Signed-off-by: Oded Gabbay
> ---
> drivers/iommu/amd_iommu_v2.c | 11 +++
> include/linux/amd-iommu.h| 2 ++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/iommu/amd_iommu_v2.c b/drivers/iommu/amd_iommu_v2.c
> index 1e6360e..2456f18 100644
> --- a/drivers/iommu/amd_iommu_v2.c
> +++ b/drivers/iommu/amd_iommu_v2.c
> @@ -895,6 +895,14 @@ out_unlock:
> }
> EXPORT_SYMBOL(amd_iommu_set_invalidate_ctx_cb);
>
> +static int iommu_v2_init_completed;
> +
> +int amd_iommu_v2_is_init_completed(void)
> +{
> + return iommu_v2_init_completed;
> +}
> +EXPORT_SYMBOL(amd_iommu_v2_is_init_completed);
> +
> static int __init amd_iommu_v2_init(void)
> {
> int ret;
> @@ -903,6 +911,7 @@ static int __init amd_iommu_v2_init(void)
>
> if (!amd_iommu_v2_supported()) {
> pr_info("AMD IOMMUv2 functionality not available on this
> system\n");
> + iommu_v2_init_completed = 1;
> /*
>* Load anyway to provide the symbols to other modules
>* which may use AMD IOMMUv2 optionally.
> @@ -919,6 +928,8 @@ static int __init amd_iommu_v2_init(void)
>
> amd_iommu_register_ppr_notifier(&ppr_nb);
>
> + iommu_v2_init_completed = 1;
> +
> return 0;
>
> out:
> diff --git a/include/linux/amd-iommu.h b/include/linux/amd-iommu.h
> index 2b08e79..115c03a 100644
> --- a/include/linux/amd-iommu.h
> +++ b/include/linux/amd-iommu.h
> @@ -169,6 +169,8 @@ typedef void (*amd_iommu_invalidate_ctx)(struct pci_dev
> *pdev, int pasid);
> extern int amd_iommu_set_invalidate_ctx_cb(struct pci_dev *pdev,
> amd_iommu_invalidate_ctx cb);
>
> +extern int amd_iommu_v2_is_init_completed(void);
> +
> #else
>
> static inline int amd_iommu_detect(void) { return -ENODEV; }
>
Hi Joerg,
This patch follows our IRC conversations from the last week.
Last update from me was that using subsys_initcall instead of module_init
does enforce amd_iommu_v2 to load _before_ amdkfd (apparently I didn't check
it correctly the first time). However, this won't help us because:
1. I don't know what effect this has when amd_iommu_v2 is compiled as module.
2. amd_iommu_v2 depends on amd_iommu which is not subsys, so amd_iommu_v2
init function fails when it is called this early, and thus, amd_iommu_v2
doesn't work.
I want to fix this situation in rc1/2, so I'm sending the complementary
patches to dri-devel in the meantime.
Oded
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lustre: ptlrpc: add "ptlrpc_internal.h" to sec_gc.c
On Sat, Dec 20, 2014 at 03:27:31PM -0500, sbaugh wrote: > ptlrpc_internal.h contains the prototypes for sptlrpc_gc_init() and > sptlrpc_gc_fini(), which are defined in sec_gc.c. > > This removes the following sparse warnings: > > drivers/staging/lustre/lustre/ptlrpc/sec_gc.c:217:5: warning: symbol > 'sptlrpc_gc_init' was not declared. Should it be static? > drivers/staging/lustre/lustre/ptlrpc/sec_gc.c:241:6: warning: symbol > 'sptlrpc_gc_fini' was not declared. Should it be static? > > Signed-off-by: sbaugh I'm guessing this is not the name you use to sign a legal document, right? Please fix that up and resend. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] bluetooth: Add hci_h4p driver
Add hci_h4p bluetooth driver. This device is used for example on Nokia N900
cell phone.
Signed-off-by: Pavel Machek
Thanks-to: Sebastian Reichel
Thanks-to: Joe Perches
---
Please apply,
Pavel
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 4547dc2..268b1a6 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -243,4 +243,13 @@ config BT_WILINK
Say Y here to compile support for Texas Instrument's WiLink7 driver
into the kernel or say M to compile it as module (btwilink).
+config BT_NOKIA_H4P
+ tristate "HCI driver with H4 Nokia extensions"
+ help
+ Bluetooth HCI driver with H4 extensions. This driver provides
+ support for H4+ Bluetooth chip with vendor-specific H4 extensions.
+
+ Say Y here to compile support for h4 extended devices into the kernel
+ or say M to compile it as module (btnokia_h4p).
+
endmenu
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 9fe8a87..624ef3fc 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -31,4 +31,7 @@ hci_uart-$(CONFIG_BT_HCIUART_ATH3K) += hci_ath.o
hci_uart-$(CONFIG_BT_HCIUART_3WIRE)+= hci_h5.o
hci_uart-objs := $(hci_uart-y)
+obj-$(CONFIG_BT_NOKIA_H4P) += nokia_h4p.o
+nokia_h4p-objs := nokia_core.o nokia_fw.o nokia_uart.o
+
ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/bluetooth/nokia_core.c b/drivers/bluetooth/nokia_core.c
new file mode 100644
index 000..163531e
--- /dev/null
+++ b/drivers/bluetooth/nokia_core.c
@@ -0,0 +1,1188 @@
+/*
+ * This file is part of Nokia H4P bluetooth driver
+ *
+ * Copyright (C) 2005-2008 Nokia Corporation.
+ * Copyright (C) 2014 Pavel Machek
+ *
+ * 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.
+ *
+ * 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 St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ * Thanks to all the Nokia people that helped with this driver,
+ * including Ville Tervo and Roger Quadros.
+ *
+ * Power saving functionality was removed from this driver to make
+ * merging easier.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "nokia_h4p.h"
+
+#undef TEST
+
+static int hw_inited = 0;
+
+/* This should be used in function that cannot release clocks */
+static void h4p_set_clk(struct h4p_info *info, int *clock, int enable)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&info->clocks_lock, flags);
+ if (enable && !*clock) {
+ BT_DBG("Enabling %p", clock);
+ clk_prepare_enable(info->uart_fclk);
+ clk_prepare_enable(info->uart_iclk);
+ if (atomic_read(&info->clk_users) == 0)
+ h4p_restore_regs(info);
+ atomic_inc(&info->clk_users);
+ }
+
+ if (!enable && *clock) {
+ BT_DBG("Disabling %p", clock);
+ if (atomic_dec_and_test(&info->clk_users))
+ h4p_store_regs(info);
+ clk_disable_unprepare(info->uart_fclk);
+ clk_disable_unprepare(info->uart_iclk);
+ }
+
+ *clock = enable;
+ spin_unlock_irqrestore(&info->clocks_lock, flags);
+}
+
+static void h4p_lazy_clock_release(unsigned long data)
+{
+ struct h4p_info *info = (struct h4p_info *)data;
+ unsigned long flags;
+
+ spin_lock_irqsave(&info->lock, flags);
+ if (!info->tx_enabled)
+ h4p_set_clk(info, &info->tx_clocks_en, 0);
+ spin_unlock_irqrestore(&info->lock, flags);
+}
+
+/* Power management functions */
+void h4p_smart_idle(struct h4p_info *info, bool enable)
+{
+ u8 v;
+
+ v = h4p_inb(info, UART_OMAP_SYSC);
+ v &= ~(UART_OMAP_SYSC_IDLEMASK);
+
+ if (enable)
+ v |= UART_OMAP_SYSC_SMART_IDLE;
+ else
+ v |= UART_OMAP_SYSC_NO_IDLE;
+
+ h4p_outb(info, UART_OMAP_SYSC, v);
+}
+
+static inline void h4p_schedule_pm(struct h4p_info *info)
+{
+}
+
+static void h4p_disable_tx(struct h4p_info *info)
+{
+ if (!info->pm_enabled)
+ return;
+
+ /* Re-enable smart-idle */
+ h4p_smart_idle(info, 1);
+
+ gpio_set_value(info->bt_wakeup_gp
Re: [PATCH] ALSA: atmel: fix building the ac97 driver for at91-multiplatform
On Friday 19 December 2014 18:02:21 Alexandre Belloni wrote: > Arnd, > > On 19/12/2014 at 17:53:44 +0300, Sergei Shtylyov wrote : > > >+#define cpu_is_at32ap7000() (0) > > > >() around 0 not needed at all. > > > > Do you want me to fix that and resubmit? I don't have strong opinion > about this. Yes, no point debating over this. I copied the definition from arch/arm/mach-at91/include/mach/cpu.h and didn't want to do any style changes, otherwise I'd probably have turned it into an inline function, but any version that works is fine with me. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] clk: changes for 3.19
The following changes since commit 206c5f60a3d902bc4b56dab2de3e88de5eb06108: Linux 3.18-rc4 (2014-11-09 14:55:29 -0800) are available in the git repository at: https://git.linaro.org/people/mike.turquette/linux.git tags/clk-for-linus-3.19 for you to fetch changes up to f1e9203e2366164b832d8a6ce10134de8c575178: clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable failure due to domain being gated (2014-12-17 07:31:51 -0800) Please consider pulling the clk framework changes toward 3.19. It is much later than usual due to several last minute bugs that had to be addressed. As usual the majority of changes are new drivers and modifications to existing drivers. The core recieved many fixes along with the groundwork for several large changes coming in the future which will better parition clock providers from clock consumers. Abhilash Kesavan (1): clk: samsung: exynos7: add gate clock for ADC block Alexandru M Stan (2): clk: rockchip: add bindings for the mmc clocks clk: rockchip: Add support for the mmc clock phases using the framework Andrzej Hajda (1): clk: samsung: exynos4: set parent of sclk_hdmiphy to hdmi Bintian Wang (1): clk: hi3620: Move const initdata into correct code section Boris Brezillon (2): clk: at91: usb: fix at91rm9200 round and set rate clk: at91: usb: fix at91sam9x5 recalc, round and set rate Chanwoo Choi (6): clk: samsung: Document binding for Exynos4415 clock controller clk: samsung: exynos4415: Add clocks using common clock framework mfd: sec-core: Add support for S2MPS13 device regulator: s2mps11: Add support S2MPS13 regulator device clk: s2mps11: Add the support for S2MPS13 PMIC clock mfd: s2mps11: Add binding documentation for Samsung S2MPS13 PMIC Chao Xie (13): clk: mmp: add prefix "mmp" for structures defined for clk-frac clk: mmp: add spin lock for clk-frac clk: mmp: add init callback for clk-frac clk: mmp: move definiton of mmp_clk_frac to clk.h clk: mmp: add clock type mix clk: mmp: add mmp private gate clock clk: mmp: add basic support functions for DT support clk: mmp: add reset support clk: mmp: add pxa168 DT support for clock driver clk: mmp: add pxa910 DT support for clock driver clk: mmp: add mmp2 DT support for clock driver arm: mmp: Make all the dts file to be compiled by Makefile arm: mmp: Make use of the DT supported clock Chen-Yu Tsai (7): clk: sunxi: make factors clock mux mask configurable clk: sunxi: Add support for A80 basic bus clocks clk: sunxi: Add support for bus clock gates on Allwinner A80 SoC ARM: dts: sunxi: Use sun4i-a10-apb1-clk for sun6i/sun8i apb2 clocks. clk: sunxi: Removed unused/incorrect sun6i-a31-apb2-clk driver clk: sunxi: Specify number of child clocks for divs clocks clk: sunxi: Implement A31 PLL6 as a divs clock for 2x output Chris Zhong (1): clk: rockchip: rk3288: add suspend and resume Dmitry Torokhov (1): clk: rockchip: ensure HCLK_VIO2_H2P and PCLK_VIO2_H2P stay enabled Doug Anderson (1): clk: rockchip: Add CLK_SET_RATE_PARENT to aclk_cpu_pre Emilio López (2): clk: sunxi: unify APB1 clock ARM: dts: sunxi: unify APB1 clock Felipe Balbi (1): ARM: OMAP2+: hwmod: drop unnecessary list initialization Geert Uytterhoeven (1): clk: shmobile: Deprecate renesas,clock-indices Georgi Djakov (1): clk: qcom: Fix duplicate rbcpr clock name Hans de Goede (2): clk_mux: Fix set_parent doing the wrong thing when INDEX_BIT && index >= 3 clk: sunxi: gmac-tx-clk mux is not a CLK_MUX_INDEX_BIT mux Heiko Stuebner (4): clk: rockchip: add ability to specify pll-specific flags clk: rockchip: setup pll_mux data earlier clk: rockchip: add optional sync to pll rate parameters clk: rockchip: add ROCKCHIP_PLL_SYNC_RATE flag to some plls Heiko Stübner (1): clk: rockchip: fix rk3188 hsadc_frac definition James Hogan (1): clk-divider: Fix READ_ONLY when divider > 1 Jeff Chen (2): clk: rockchip: add binding ID for DMC (memory controller) clocks on rk3288 clk: rockchip: use clock ID for DMC (memory controller) on rk3288 Jianqun (1): clk: rockchip: rk3288: removing the CLK_SET_RATE_PARENT from i2s_clkout Julien CHAUVEAU (3): clk: rockchip: fix parent clock for rk3188 hclk_lcdc1 clk: rockchip: fix clock gate for rk3188 spdif_pre clk: rockchip: fix rk3188 USB HSIC PHY clock divider Kever Yang (6): clk: rockchip: add 400MHz and 500MHz for rk3288 clock rate clk: rockchip: add npll to source of sclk_gpu clk: rockchip: change PLL setting for better clock jitter clk: rockchip: disable unused clocks clk: rockchip: fix rk3288 clk_usbphy480m_gate bit location in r
[PATCH] lustre: ptlrpc: add "ptlrpc_internal.h" to sec_gc.c
ptlrpc_internal.h contains the prototypes for sptlrpc_gc_init() and sptlrpc_gc_fini(), which are defined in sec_gc.c. This removes the following sparse warnings: drivers/staging/lustre/lustre/ptlrpc/sec_gc.c:217:5: warning: symbol 'sptlrpc_gc_init' was not declared. Should it be static? drivers/staging/lustre/lustre/ptlrpc/sec_gc.c:241:6: warning: symbol 'sptlrpc_gc_fini' was not declared. Should it be static? Signed-off-by: sbaugh --- drivers/staging/lustre/lustre/ptlrpc/sec_gc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/lustre/lustre/ptlrpc/sec_gc.c b/drivers/staging/lustre/lustre/ptlrpc/sec_gc.c index c500aff..81de68e 100644 --- a/drivers/staging/lustre/lustre/ptlrpc/sec_gc.c +++ b/drivers/staging/lustre/lustre/ptlrpc/sec_gc.c @@ -47,6 +47,8 @@ #include "../include/lustre_net.h" #include "../include/lustre_sec.h" +#include "ptlrpc_internal.h" + #define SEC_GC_INTERVAL (30 * 60) -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] printk: Correct timeout comment, neaten MODULE_PARM_DESC
Neaten the MODULE_PARAM_DESC message.
Use 30 seconds in the comment for the zap console locks timeout.
Signed-off-by: Joe Perches
---
kernel/printk/printk.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 02d6b6d..c06df7d 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -935,8 +935,8 @@ static int __init ignore_loglevel_setup(char *str)
early_param("ignore_loglevel", ignore_loglevel_setup);
module_param(ignore_loglevel, bool, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(ignore_loglevel, "ignore loglevel setting, to"
- "print all kernel messages to the console.");
+MODULE_PARM_DESC(ignore_loglevel,
+"ignore loglevel setting (prints all kernel messages to the
console)");
#ifdef CONFIG_BOOT_PRINTK_DELAY
@@ -1419,16 +1419,16 @@ static void call_console_drivers(int level, const char
*text, size_t len)
}
/*
- * Zap console related locks when oopsing. Only zap at most once
- * every 10 seconds, to leave time for slow consoles to print a
- * full oops.
+ * Zap console related locks when oopsing.
+ * To leave time for slow consoles to print a full oops,
+ * only zap at most once every 30 seconds.
*/
static void zap_locks(void)
{
static unsigned long oops_timestamp;
if (time_after_eq(jiffies, oops_timestamp) &&
- !time_after(jiffies, oops_timestamp + 30 * HZ))
+ !time_after(jiffies, oops_timestamp + 30 * HZ))
return;
oops_timestamp = jiffies;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] dell-wmi: Don't send unneeded keypresses
On Sat, Dec 20, 2014 at 06:03:54PM +0100, Gabriele Mazzotta wrote: > On Saturday 20 December 2014 08:16:54 Darren Hart wrote: > > On Sat, Dec 20, 2014 at 04:11:08PM +0100, Pavel Machek wrote: > > > Hi! > > > > > > > > > Ok, I agree that it is subjective how serious it is... > > > > > > Just to remind that patch fixing problem described in > > > > > > > > > > > > http://www.spinics.net/lists/platform-driver-x86/msg05922.ht > > > > > > ml > > > > > > http://www.spinics.net/lists/platform-driver-x86/msg05924.h > > > > > > tml > > > > > > > > > > I don't have any objection to sending this back to stable. > > > > > Stable is for fixing REAL bugs, as opposed to theorhetical > > > > > races, etc. This is a "real" bug. > > > > > > > > > > As to not chaning behavior, if it's OK for mainline, it's OK > > > > > for stable. At least that is my understanding of it. Folks > > > > > are free to verify with Greg if they disagree. > > > > > > > > Darren, so how you decided? Now when patches are in linus tree, > > > > are you going to send them to stable tree? > > > > > > Please don't. -stable is for serious mainline bugs people are actually > > > hitting. Null pointer dereference counts, if people actually hit > > > it. This is more behaviour change, and yes, the new behaviour is > > > better, but it is really different class. > > > > In this case I agree with Pavel. While the patches are small enough, fix one > > thing each, etc, it isn't clear from the description exactly how these > > patches > > affect users. > > > > If you can articulate how they are "real bugs that bother people" (see > > stable_kernel_rules.txt) we can reconsider. I should have pushed for better > > commit messages on these it appears as this should be obvious from those, > > but it > > isn't - at least not to me at 8:15am ;-) > > The problem is that userspace programs responds to those keypresses when > they shouldn't. > > In case of KEY_KBDILLUMTOGGLE, the illumination level is changed by the > BIOS, so if the keypress is reported, userspace programs will try to > toggle the keyboard illumination after the BIOS changed the level. > This is even more problematic if you consider that there could be > multiple illumination levels that are not taken into account if a > KEY_KBDILLUMTOGGLE is sent. Userspace will simply turn ON/OFF the > illumination, interfering with the BIOS. > This is shouldn't be a major problem since dell-laptop can control the > keyboard illumination only now and I can't see what userspace > application can misbehave without this change. Agreed, this one should not go back to stable. > > In the case of KEY_WLAN/KEY_RFKILL, the BIOS already takes care of > everything when the key is pressed, so sending keypresses as if > userspace programs have to do something is wrong. If for instance the > WiFi rfkill is soft blocked and I press the Fn key twice, I want it > to be soft blocked at the end. However, this is not the case. These sound like good candidates, real bugs that bother people. I would support sending them back to stable. Since we didn't have this discussion before they went mainline, sorry it's been a bad month for me :-/, these need to be sent manually. Pali, Gabriele, please have a look at stable_kernel_rules, determine how far back these should go, and submit the patches to the stable list. > Sorry for the brief commit messages. > They didn't bother me at the time as I saw the improvement, but they weren't enough to make the stable decision and I need to watch out for that in the future. Lesson learned :-) Thanks everyone, -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] iommu/amd: Track when amd_iommu_v2 init is complete
This patch adds a new exported function to amd_iommu_v2, which returns 1 if the
amd_iommu_v2 initialization function has completed, and 0 otherwise.
This is necessary for the case when amd_iommu_v2 is compiled inside the kernel
image (not as module) and another module (e.g. amdkfd), which is also compiled
inside the kernel image, is dependent on amd_iommu_v2 functionality.
In that case, there is no mechanism in the kernel that enforces the order of
loading between the two modules. Therefore, If the amd_iommu_v2 is loaded
_after_ the other module, and the other module calls one of
amd_iommu_v2 exported functions _before_ amd_iommu_v2 is loaded, than that
function will fail, and as a result, the calling module may fail as well.
Note that when the two modules are compiled as modules, this situation can't
occur as the kernel enforces the order of loading.
Signed-off-by: Oded Gabbay
---
drivers/iommu/amd_iommu_v2.c | 11 +++
include/linux/amd-iommu.h| 2 ++
2 files changed, 13 insertions(+)
diff --git a/drivers/iommu/amd_iommu_v2.c b/drivers/iommu/amd_iommu_v2.c
index 1e6360e..2456f18 100644
--- a/drivers/iommu/amd_iommu_v2.c
+++ b/drivers/iommu/amd_iommu_v2.c
@@ -895,6 +895,14 @@ out_unlock:
}
EXPORT_SYMBOL(amd_iommu_set_invalidate_ctx_cb);
+static int iommu_v2_init_completed;
+
+int amd_iommu_v2_is_init_completed(void)
+{
+ return iommu_v2_init_completed;
+}
+EXPORT_SYMBOL(amd_iommu_v2_is_init_completed);
+
static int __init amd_iommu_v2_init(void)
{
int ret;
@@ -903,6 +911,7 @@ static int __init amd_iommu_v2_init(void)
if (!amd_iommu_v2_supported()) {
pr_info("AMD IOMMUv2 functionality not available on this
system\n");
+ iommu_v2_init_completed = 1;
/*
* Load anyway to provide the symbols to other modules
* which may use AMD IOMMUv2 optionally.
@@ -919,6 +928,8 @@ static int __init amd_iommu_v2_init(void)
amd_iommu_register_ppr_notifier(&ppr_nb);
+ iommu_v2_init_completed = 1;
+
return 0;
out:
diff --git a/include/linux/amd-iommu.h b/include/linux/amd-iommu.h
index 2b08e79..115c03a 100644
--- a/include/linux/amd-iommu.h
+++ b/include/linux/amd-iommu.h
@@ -169,6 +169,8 @@ typedef void (*amd_iommu_invalidate_ctx)(struct pci_dev
*pdev, int pasid);
extern int amd_iommu_set_invalidate_ctx_cb(struct pci_dev *pdev,
amd_iommu_invalidate_ctx cb);
+extern int amd_iommu_v2_is_init_completed(void);
+
#else
static inline int amd_iommu_detect(void) { return -ENODEV; }
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: cottula: add cottula board
On Saturday 20 December 2014 10:43:48 Robert Jarzmik wrote: > Robert Jarzmik writes: > > Arnd Bergmann writes: > >> This looks a bit ambiguous: You get a GPIO line for the purpose of the > >> IRQ nesting but don't use the GPIO otherwise, and you pass the device's > >> own irq domain start as an IORESOURCE_IRQ resource. > >> > >> For consistency between DT and ATAGS based uses, and with similar DT > >> based drivers, I would instead recommend passing the parent irq (from > >> the GPIO) as an IORESOURCE_IRQ resource instead of a gpio lookup, > >> and passing the base_irq as platform_data for the ATAGS case. > > Hi Arnd, > > I thought again about the GPIO. > > I put in the "gpiod_get()" call to ensure proper ordering between the gpio > probing and this driver probing. It ensured that this driver's probe will be > defered until the gpio driver is probed, which is the main purpose of this > patch (commit message). > > If I pass an irq from the machine code, I loose this guarantee, don't I ? Not sure, my guess is that it could still work the same way because the irq is not registered yet and request_irq or similar will fail. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] arm64: dts: Add mediatek MT8173 SoC and evaluation board dts and Makefile
On Wednesday 17 December 2014 15:01:29 Marc Zyngier wrote: > > Indeed, as described in the documentation: > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/CHDIFAEE.html > > Also it is worth noticing that given how GICV is placed, it will never > work with 64K pages and virtualization. Pretty sad. Does this mean no VGIC support on this platform so you have to emulate it in order to run virtual machines with 64K pages, or does it mean that it's impossible to use that way because you can't emulate it? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: SAMSUNG: remove dead #elif CONFIG_S3C24XX_DMAC
On Friday 19 December 2014 15:15:09 Stefan Hengelein wrote: > From what i can see, the block was already dead when it was introduced. > d2193ce2 changed the "if ARCH_S3C64XX" into the Kconfig file itself, > before it was around the source statement in arch/arm/Kconfig > > if there are really just downstream users that explicitly have to add > a statement to select S3C64XX_DEV_SPI0 and therefore add the > possibility to enable the block i want to remove, i'd argue that these > downstream users could also add the block itself. I'm not sure how > intuitive it might be for downstream users to add a select in Kconfig > to enable their machine to communicate with a device, but i'm also not > familiar with the hardware we're talking about. > > However, i'd prefer to have a consistent upstream state and leave > these problems to downstream users, but that's for the Maintainer to > decide In general, I totally agree: dead code should be eliminated and out of tree users of dead code can add it back as a patch. However, in this case, I'd lean more towards leaving the code in there, basically because the current code correctly documents what the hardware requirements are, and that is helpful even for reading the code when you work on DT based support for the same hardware. Eventually we will be able to remove the entire function. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] proc: task_mmu: show page size in /proc//numa_maps
On Sat, Dec 20, 2014 at 01:36:13PM -0500, Johannes Weiner wrote:
> On Sat, Dec 20, 2014 at 08:54:45AM -0500, Rafael Aquini wrote:
> > This patch introduces 'pagesize' line element to /proc//numa_maps
> > report file in order to help disambiguating the size of pages that are
> > backing memory areas mapped by a task. When the VMA backing page size
> > is observed different from kernel's default PAGE_SIZE, the new element
> > is printed out to complement report output. This is specially useful to
> > help differentiating between HUGE and GIGANTIC page VMAs.
> >
> > This patch is based on Dave Hansen's proposal and reviewer's follow ups
> > taken from this dicussion: https://lkml.org/lkml/2011/9/21/454
> >
> > Signed-off-by: Rafael Aquini
> > ---
> > fs/proc/task_mmu.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> > index 246eae8..9f2e2c8 100644
> > --- a/fs/proc/task_mmu.c
> > +++ b/fs/proc/task_mmu.c
> > @@ -1479,6 +1479,7 @@ static int show_numa_map(struct seq_file *m, void *v,
> > int is_pid)
> > struct mm_struct *mm = vma->vm_mm;
> > struct mm_walk walk = {};
> > struct mempolicy *pol;
> > + unsigned long page_size;
> > char buffer[64];
> > int nid;
> >
> > @@ -1533,6 +1534,10 @@ static int show_numa_map(struct seq_file *m, void
> > *v, int is_pid)
> > if (!md->pages)
> > goto out;
> >
> > + page_size = vma_kernel_pagesize(vma);
> > + if (page_size != PAGE_SIZE)
> > + seq_printf(m, " pagesize=%lu", page_size);
>
> It would be simpler to include this unconditionally. Otherwise you
> are forcing everybody parsing the file and trying to run calculations
> of it to check for its presence, and then have them fall back and get
> the value from somewhere else if not.
I'm fine either way, it makes the change even simpler. Also, if we
decide to get rid of page_size != PAGE_SIZE condition I believe we can
also get rid of that "huge" hint being conditionally printed out too.
-- Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PULL REQUEST] i2c for 3.19
Linus, here is a second pull request for I2C. Included are two bugfixes needing some bigger refactoring (sh_mobile: deferred probe with DMA, mv64xxx: fix offload support) and one deprecated driver removal I thought would go in via ppc but I misunderstood. It has a proper ack from BenH. Please pull, Wolfram The following changes since commit 603ba7e41bf5d405aba22294af5d075d8898176d: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2014-12-16 15:53:03 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next for you to fetch changes up to fe07adec730d271c91f4160f96a0f24fe7553c63: i2c: sh_mobile: fix uninitialized var when debug is enabled (2014-12-20 09:28:09 +0100) Geert Uytterhoeven (1): i2c: sh_mobile: I2C_SH_MOBILE should depend on HAS_DMA Thomas Petazzoni (2): i2c: mv64xxx: use BIT() macro for register value definitions i2c: mv64xxx: rework offload support to fix several problems Wolfram Sang (4): i2c: sh_mobile: refactor DMA setup i2c: sh_mobile: rework deferred probing macintosh: therm_pm72: delete deprecated driver i2c: sh_mobile: fix uninitialized var when debug is enabled drivers/i2c/busses/Kconfig |1 + drivers/i2c/busses/i2c-mv64xxx.c | 328 +++--- drivers/i2c/busses/i2c-sh_mobile.c | 112 +- drivers/macintosh/Kconfig | 10 - drivers/macintosh/Makefile |1 - drivers/macintosh/therm_pm72.c | 2278 drivers/macintosh/therm_pm72.h | 326 -- 7 files changed, 252 insertions(+), 2804 deletions(-) delete mode 100644 drivers/macintosh/therm_pm72.c delete mode 100644 drivers/macintosh/therm_pm72.h signature.asc Description: Digital signature
Re: [PATCH v2 0/6] net-PPP: Deletion of a few unnecessary checks
From: SF Markus Elfring Date: Sat, 20 Dec 2014 15:45:32 +0100 > I hope that you will find a bit time and patience again > to clarify affected implementation details in a safer and > unambiguous way. Sorry, another developer will have to hold your hand, as I said I already invested too much time into this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] gpu: drm: sti: sti_drm_crtc.c: Remove unused function
Hello,
Please do not apply this patch, this function is use in the next I have submit:
http://lists.freedesktop.org/archives/dri-devel/2014-December/074073.html
Regards,
Benjamin
2014-12-20 18:17 GMT+01:00 Rickard Strandqvist
:
> Remove the function sti_drm_crtc_is_main() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/drm/sti/sti_drm_crtc.c | 10 --
> drivers/gpu/drm/sti/sti_drm_crtc.h |1 -
> 2 files changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_drm_crtc.c
> b/drivers/gpu/drm/sti/sti_drm_crtc.c
> index d2ae0c0..be53e35 100644
> --- a/drivers/gpu/drm/sti/sti_drm_crtc.c
> +++ b/drivers/gpu/drm/sti/sti_drm_crtc.c
> @@ -389,16 +389,6 @@ static struct drm_crtc_funcs sti_crtc_funcs = {
> .set_property = sti_drm_crtc_set_property,
> };
>
> -bool sti_drm_crtc_is_main(struct drm_crtc *crtc)
> -{
> - struct sti_mixer *mixer = to_sti_mixer(crtc);
> -
> - if (mixer->id == STI_MIXER_MAIN)
> - return true;
> -
> - return false;
> -}
> -
> int sti_drm_crtc_init(struct drm_device *drm_dev, struct sti_mixer *mixer,
> struct drm_plane *primary, struct drm_plane *cursor)
> {
> diff --git a/drivers/gpu/drm/sti/sti_drm_crtc.h
> b/drivers/gpu/drm/sti/sti_drm_crtc.h
> index caca8b1..ddae8fe 100644
> --- a/drivers/gpu/drm/sti/sti_drm_crtc.h
> +++ b/drivers/gpu/drm/sti/sti_drm_crtc.h
> @@ -17,6 +17,5 @@ int sti_drm_crtc_enable_vblank(struct drm_device *dev, int
> crtc);
> void sti_drm_crtc_disable_vblank(struct drm_device *dev, int crtc);
> int sti_drm_crtc_vblank_cb(struct notifier_block *nb,
> unsigned long event, void *data);
> -bool sti_drm_crtc_is_main(struct drm_crtc *drm_crtc);
>
> #endif
> --
> 1.7.10.4
>
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] i8k: Autodetect maximal fan speed and fan RPM multiplier
On 12/19/2014 10:04 AM, Pali Rohár wrote:
This patch adds new function i8k_get_fan_nominal_speed() for doing SMM call
which will return nominal fan RPM for specified fan speed. It returns nominal
RPM value at which fan operate when speed (0, 1, 2, 3) is set. It looks like
RPM value is not accurate, but still provides very useful information.
First it can be used to validate if certain fan speed could be accepted by SMM
for setting fan speed and we can use this routine to detect maximal fan speed.
Second it returns RPM value, so we can check if value looks correct with
multiplier 30 or multiplier 1 (until now only these two multiplier were used).
If RPM value with multiplier 30 is too high, then multiplier 1 is used.
In case when SMM reports that new function is not supported we will fallback
to old hardcoded values. Maximal fan speed would be 2 and RPM multiplier 30.
Signed-off-by: Pali Rohár
Tested-By: Pali Rohár
Tested-By: Steven Honeyman
Tested-By: Valdis Kletnieks
---
drivers/char/i8k.c | 126 +++-
1 file changed, 105 insertions(+), 21 deletions(-)
diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index 48d701c..094a6b8 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -6,6 +6,7 @@
* Hwmon integration:
* Copyright (C) 2011 Jean Delvare
* Copyright (C) 2013, 2014 Guenter Roeck
+ * Copyright (C) 2014 Pali Rohár
*
* 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
@@ -42,12 +43,14 @@
#define I8K_SMM_SET_FAN 0x01a3
#define I8K_SMM_GET_FAN 0x00a3
#define I8K_SMM_GET_SPEED 0x02a3
+#define I8K_SMM_GET_NOM_SPEED 0x04a3
#define I8K_SMM_GET_TEMP 0x10a3
#define I8K_SMM_GET_TEMP_TYPE 0x11a3
#define I8K_SMM_GET_DELL_SIG1 0xfea3
#define I8K_SMM_GET_DELL_SIG2 0xffa3
-#define I8K_FAN_MULT 30
+#define I8K_FAN_DEFAULT_MULT 30
+#define I8K_FAN_MAX_RPM3
#define I8K_MAX_TEMP 127
#define I8K_FN_NONE 0x00
@@ -64,9 +67,9 @@ static DEFINE_MUTEX(i8k_mutex);
static char bios_version[4];
static struct device *i8k_hwmon_dev;
static u32 i8k_hwmon_flags;
-static int i8k_fan_mult;
-static int i8k_pwm_mult;
-static int i8k_fan_max = I8K_FAN_HIGH;
+static int i8k_fan_mult[2];
+static int i8k_pwm_mult[2];
+static int i8k_fan_max[2];
#define I8K_HWMON_HAVE_TEMP1 (1 << 0)
#define I8K_HWMON_HAVE_TEMP2 (1 << 1)
@@ -95,13 +98,13 @@ static bool power_status;
module_param(power_status, bool, 0600);
MODULE_PARM_DESC(power_status, "Report power status in /proc/i8k");
-static int fan_mult = I8K_FAN_MULT;
+static int fan_mult;
module_param(fan_mult, int, 0);
-MODULE_PARM_DESC(fan_mult, "Factor to multiply fan speed with");
+MODULE_PARM_DESC(fan_mult, "Factor to multiply fan speed with (default:
autodetect)");
-static int fan_max = I8K_FAN_HIGH;
+static int fan_max;
module_param(fan_max, int, 0);
-MODULE_PARM_DESC(fan_max, "Maximum configurable fan speed");
+MODULE_PARM_DESC(fan_max, "Maximum configurable fan speed (default:
autodetect)");
static int i8k_open_fs(struct inode *inode, struct file *file);
static long i8k_ioctl(struct file *, unsigned int, unsigned long);
@@ -271,8 +274,25 @@ static int i8k_get_fan_speed(int fan)
{
struct smm_regs regs = { .eax = I8K_SMM_GET_SPEED, };
+ if (fan < 0 || fan >= ARRAY_SIZE(i8k_fan_mult))
+ return -EINVAL;
+
regs.ebx = fan & 0xff;
- return i8k_smm(®s) ? : (regs.eax & 0x) * i8k_fan_mult;
+ return i8k_smm(®s) ? : (regs.eax & 0x) * i8k_fan_mult[fan];
+}
+
+/*
+ * Read the fan nominal rpm for specific fan speed.
+ */
+static int i8k_get_fan_nominal_speed(int fan, int speed)
+{
+ struct smm_regs regs = { .eax = I8K_SMM_GET_NOM_SPEED, };
+
+ if (fan < 0 || fan >= ARRAY_SIZE(i8k_fan_mult))
+ return -EINVAL;
+
+ regs.ebx = (fan & 0xff) | (speed << 8);
+ return i8k_smm(®s) ? : (regs.eax & 0x) * i8k_fan_mult[fan];
}
/*
@@ -282,9 +302,12 @@ static int i8k_set_fan(int fan, int speed)
{
struct smm_regs regs = { .eax = I8K_SMM_SET_FAN, };
- speed = (speed < 0) ? 0 : ((speed > i8k_fan_max) ? i8k_fan_max : speed);
- regs.ebx = (fan & 0xff) | (speed << 8);
+ if (speed < 0)
+ speed = 0;
+ if (fan >= 0 && fan < ARRAY_SIZE(i8k_fan_max) && speed >
i8k_fan_max[fan])
+ speed = i8k_fan_max[fan];
+ regs.ebx = (fan & 0xff) | (speed << 8);
return i8k_smm(®s) ? : i8k_get_fan_status(fan);
}
@@ -562,7 +585,8 @@ static ssize_t i8k_hwmon_show_pwm(struct device *dev,
status = i8k_get_fan_status(index);
if (status < 0)
return -EIO;
- return sprintf(buf, "%d\n", clamp_val(status * i8k_pwm_mult, 0, 255));
+ return sprintf(buf, "%d\n", clamp_val(status * i8k_pwm_mult[index],
+
Re: [RFC PATCH 2/2] iommu: rockchip: Handle system-wide and runtime PM
Hi Kevin, On Friday 19 December 2014 03:27:35 Rafael J. Wysocki wrote: > On Thursday, December 18, 2014 11:28:58 PM Laurent Pinchart wrote: > > Hi Kevin, > > [cut] > > It would be better to be able to reference count the DMA engine from > the bus master IMO and arguably you can use the runtime PM framework > for that. Namely, give bus masters someting like > > pm_runtime_get_my_DMA_engine(bus_master_device) > pm_runtime_put_my_DMA_engine(bus_master_device) > > and let them call these as they see fit. Please note that we're not talking about DMA engines here, but about IOMMUs. DMA is involved through the DMA mapping API which hides the IOMMU completely from the bus master drivers, not the DMA engine API. Exposing the IOMMU is something we want to avoid, but DMA mapping start/stop operations could certainly be implemented. >>> >>> The problem with that is it only solves the IOMMU problem. We have a >>> more generic PM dependency problem of which this IOMMU example is only a >>> subset, so I think we need a more generic solution. >> >> I agree that a more generic solution is needed at least to support ACPI >> _DEP, but that might not be optimal in the IOMMU use case as explained >> above. > > Well, since we need it anyway, why don't we implement it and then figure out > if anything more specific needs to be done for the IOMMU case? Patches are welcome ;-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] dell-wmi: Don't send unneeded keypresses
On Sat 2014-12-20 18:02:49, Pali Rohár wrote: > 2014-12-20 17:28 GMT+01:00 Henrique de Moraes Holschuh : > > > On Sat, 20 Dec 2014, Pavel Machek wrote: > > > > > > Ok, I agree that it is subjective how serious it is... > > > > > > Just to remind that patch fixing problem described in > > > > > > > > > > > > http://www.spinics.net/lists/platform-driver-x86/msg05922.ht > > > > > > ml > > > > > > http://www.spinics.net/lists/platform-driver-x86/msg05924.h > > > > > > tml > > > > > > > > > > I don't have any objection to sending this back to stable. > > > > > Stable is for fixing REAL bugs, as opposed to theorhetical > > > > > races, etc. This is a "real" bug. > > > > > > > > > > As to not chaning behavior, if it's OK for mainline, it's OK > > > > > for stable. At least that is my understanding of it. Folks > > > > > are free to verify with Greg if they disagree. > > > > > > > > Darren, so how you decided? Now when patches are in linus tree, > > > > are you going to send them to stable tree? > > > > > > Please don't. -stable is for serious mainline bugs people are actually > > > hitting. Null pointer dereference counts, if people actually hit > > > it. This is more behaviour change, and yes, the new behaviour is > > > better, but it is really different class. > > > > Sometimes the old behavior is something that is a major pain for users and > > userspace. In that case, where the new behavior fixes really annoying > > usecase bugs, the fix belongs in -stable IMHO. > > > > Broken behavior hits, by definition, every user of the feature after all. > > > > -- > > "One disk to rule them all, One disk to find them. One disk to bring > > them all and in the darkness grind them. In the Land of Redmond > > where the shadows lie." -- The Silicon Valley Tarot > > Henrique Holschuh > > > > Ok, I'm asking. It's up to you how you decide. Problem with keyboard > illumination button is that BIOS change keyboard backlight plus it send > keycode. So if you have userspace application which listening for > illumination button and then do something with that event (e.g change > keyboard backlight) you will get duplicate actions (or cyclic events, etc). > But if you think that this change should not go to stable tree, its ok. I'm > just ask how you decide... Well, user report "keyboard illumination does not work in GNOME 3.14159 on Mandriva 1.732 and this patch fixes it" would certainly help. But I'm afraid that Fedora 1.4142 already knows and expects those duplicate events. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.18.1: broken directory with one file too many
On 12/20/14 19:02, J. Bruce Fields wrote: > Gah. Does this fix it? It does! Well done. :) Reported-by: Holger Hoffstätte Tested-by: Holger Hoffstätte Thanks! Holger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 11/12] ARM: dts: add support for Vybrid running on Cortex-M4
On 2014-12-18 23:44, Arnd Bergmann wrote: > On Thursday 18 December 2014 21:36:31 Stefan Agner wrote: >> On 2014-12-17 13:31, Arnd Bergmann wrote: >> > On Wednesday 17 December 2014 00:41:33 Stefan Agner wrote: >> >> On 2014-12-03 12:03, Arnd Bergmann wrote: >> >> > Starting with v3.19, you should be able to use the earlycon framework on >> >> > arm32, so it would be better to replace earlyprintk with earlycon here >> >> > and add a stdout-path property in chosen that points to the console >> >> > uart. >> >> >> >> I started to implement earlycon support, but something currently fails >> >> when earlycon tries to map the UART registers: >> >> [0.00] earlycon_map: Couldn't map 0x40027000 >> >> >> >> I traced the issue a bit further down and found that get_vm_area_caller >> >> returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master >> >> as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss >> >> something here? >> > >> > Hmm, I fear the arm32 FIX_EARLYCON_MEM support ended up not making it >> > into 3.19 after all. >> >> Is it because early_ioremap and fixmap still missing for arm32? >> According to Rob's patchset from spring fixmap is required, there is >> something in this tree: >> https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/log/?h=arm-fixmap > > Right, that's the one, thanks for finding that again. There are five > patches on that branch. The first three got merged, and the one we > need is just the last one (ARM: fixmap early permanent mapping support), > but the implementation depends on the previous patch (arm: add > early_ioremap support). > > I was hoping we'd see both of them in 3.19, but apparently Rob didn't > submit the latest version. If you don't mind, could you try forward-porting > them to the latest kernel and then submit them for inclusion? You could > also try adapting the last patch to work without the early_ioremap > support that we don't really need that urgently on arm32. Looked into that a bit more in depth. I tried creating a patch which adds just what is necessary to support FIX_EARLYCON_MEM. Fixmap seems to be in place, just for earlycon it would need a fixmap entry with FIX_EARLYCON_MEM_BASE. And I guess later during boot, it would need a call to create_mapping to create a permanent mapping of it. Currently I'm stuck in the __set_fixmap call, on set_pte_ext call the kernel freezes. The arguments look fine as far as I can tell (vaddr ffeff000, phys 40027000, pgprot is FIXMAP_PAGE_IO, defined as in Rob's patchset). Afaik, initialization for early fixmap is missing, I guess we could do something which looks similar to what ARM64 has now: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=af86e5974d3069bd26ebcf7c046c6e59726acaaa I'm wondering what the value is of __set_fixmap without that, as is right now? I still need to understand the whole MM stuff a bit more. I will be away the next couple of days, but will have a look into it towards the end of the year. But if anyone else can help make that happen (who might be better in the picture of fixmap than I am), I'm happy too :-) -- 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 v2 1/2] i8k: Autodetect maximal fan speed and fan RPM multiplier
On 12/19/2014 10:04 AM, Pali Rohár wrote:
This patch adds new function i8k_get_fan_nominal_speed() for doing SMM call
which will return nominal fan RPM for specified fan speed. It returns nominal
RPM value at which fan operate when speed (0, 1, 2, 3) is set. It looks like
RPM value is not accurate, but still provides very useful information.
First it can be used to validate if certain fan speed could be accepted by SMM
for setting fan speed and we can use this routine to detect maximal fan speed.
Second it returns RPM value, so we can check if value looks correct with
multiplier 30 or multiplier 1 (until now only these two multiplier were used).
If RPM value with multiplier 30 is too high, then multiplier 1 is used.
In case when SMM reports that new function is not supported we will fallback
to old hardcoded values. Maximal fan speed would be 2 and RPM multiplier 30.
Signed-off-by: Pali Rohár
Tested-By: Pali Rohár
Tested-By: Steven Honeyman
Tested-By: Valdis Kletnieks
---
drivers/char/i8k.c | 126 +++-
1 file changed, 105 insertions(+), 21 deletions(-)
diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index 48d701c..094a6b8 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -6,6 +6,7 @@
* Hwmon integration:
* Copyright (C) 2011 Jean Delvare
* Copyright (C) 2013, 2014 Guenter Roeck
+ * Copyright (C) 2014 Pali Rohár
*
* 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
@@ -42,12 +43,14 @@
#define I8K_SMM_SET_FAN 0x01a3
#define I8K_SMM_GET_FAN 0x00a3
#define I8K_SMM_GET_SPEED 0x02a3
+#define I8K_SMM_GET_NOM_SPEED 0x04a3
#define I8K_SMM_GET_TEMP 0x10a3
#define I8K_SMM_GET_TEMP_TYPE 0x11a3
#define I8K_SMM_GET_DELL_SIG1 0xfea3
#define I8K_SMM_GET_DELL_SIG2 0xffa3
-#define I8K_FAN_MULT 30
+#define I8K_FAN_DEFAULT_MULT 30
+#define I8K_FAN_MAX_RPM3
#define I8K_MAX_TEMP 127
#define I8K_FN_NONE 0x00
@@ -64,9 +67,9 @@ static DEFINE_MUTEX(i8k_mutex);
static char bios_version[4];
static struct device *i8k_hwmon_dev;
static u32 i8k_hwmon_flags;
-static int i8k_fan_mult;
-static int i8k_pwm_mult;
-static int i8k_fan_max = I8K_FAN_HIGH;
+static int i8k_fan_mult[2];
+static int i8k_pwm_mult[2];
+static int i8k_fan_max[2];
#define I8K_HWMON_HAVE_TEMP1 (1 << 0)
#define I8K_HWMON_HAVE_TEMP2 (1 << 1)
@@ -95,13 +98,13 @@ static bool power_status;
module_param(power_status, bool, 0600);
MODULE_PARM_DESC(power_status, "Report power status in /proc/i8k");
-static int fan_mult = I8K_FAN_MULT;
+static int fan_mult;
module_param(fan_mult, int, 0);
-MODULE_PARM_DESC(fan_mult, "Factor to multiply fan speed with");
+MODULE_PARM_DESC(fan_mult, "Factor to multiply fan speed with (default:
autodetect)");
-static int fan_max = I8K_FAN_HIGH;
+static int fan_max;
module_param(fan_max, int, 0);
-MODULE_PARM_DESC(fan_max, "Maximum configurable fan speed");
+MODULE_PARM_DESC(fan_max, "Maximum configurable fan speed (default:
autodetect)");
static int i8k_open_fs(struct inode *inode, struct file *file);
static long i8k_ioctl(struct file *, unsigned int, unsigned long);
@@ -271,8 +274,25 @@ static int i8k_get_fan_speed(int fan)
{
struct smm_regs regs = { .eax = I8K_SMM_GET_SPEED, };
+ if (fan < 0 || fan >= ARRAY_SIZE(i8k_fan_mult))
+ return -EINVAL;
+
regs.ebx = fan & 0xff;
- return i8k_smm(®s) ? : (regs.eax & 0x) * i8k_fan_mult;
+ return i8k_smm(®s) ? : (regs.eax & 0x) * i8k_fan_mult[fan];
+}
+
+/*
+ * Read the fan nominal rpm for specific fan speed.
+ */
+static int i8k_get_fan_nominal_speed(int fan, int speed)
+{
+ struct smm_regs regs = { .eax = I8K_SMM_GET_NOM_SPEED, };
+
+ if (fan < 0 || fan >= ARRAY_SIZE(i8k_fan_mult))
+ return -EINVAL;
+
+ regs.ebx = (fan & 0xff) | (speed << 8);
+ return i8k_smm(®s) ? : (regs.eax & 0x) * i8k_fan_mult[fan];
}
/*
@@ -282,9 +302,12 @@ static int i8k_set_fan(int fan, int speed)
{
struct smm_regs regs = { .eax = I8K_SMM_SET_FAN, };
- speed = (speed < 0) ? 0 : ((speed > i8k_fan_max) ? i8k_fan_max : speed);
- regs.ebx = (fan & 0xff) | (speed << 8);
+ if (speed < 0)
+ speed = 0;
+ if (fan >= 0 && fan < ARRAY_SIZE(i8k_fan_max) && speed >
i8k_fan_max[fan])
+ speed = i8k_fan_max[fan];
+ regs.ebx = (fan & 0xff) | (speed << 8);
return i8k_smm(®s) ? : i8k_get_fan_status(fan);
}
@@ -562,7 +585,8 @@ static ssize_t i8k_hwmon_show_pwm(struct device *dev,
status = i8k_get_fan_status(index);
if (status < 0)
return -EIO;
- return sprintf(buf, "%d\n", clamp_val(status * i8k_pwm_mult, 0, 255));
+ return sprintf(buf, "%d\n", clamp_val(status * i8k_pwm_mult[index],
+
Re: [PATCH] proc: task_mmu: show page size in /proc//numa_maps
On Sat, Dec 20, 2014 at 08:54:45AM -0500, Rafael Aquini wrote:
> This patch introduces 'pagesize' line element to /proc//numa_maps
> report file in order to help disambiguating the size of pages that are
> backing memory areas mapped by a task. When the VMA backing page size
> is observed different from kernel's default PAGE_SIZE, the new element
> is printed out to complement report output. This is specially useful to
> help differentiating between HUGE and GIGANTIC page VMAs.
>
> This patch is based on Dave Hansen's proposal and reviewer's follow ups
> taken from this dicussion: https://lkml.org/lkml/2011/9/21/454
>
> Signed-off-by: Rafael Aquini
> ---
> fs/proc/task_mmu.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 246eae8..9f2e2c8 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1479,6 +1479,7 @@ static int show_numa_map(struct seq_file *m, void *v,
> int is_pid)
> struct mm_struct *mm = vma->vm_mm;
> struct mm_walk walk = {};
> struct mempolicy *pol;
> + unsigned long page_size;
> char buffer[64];
> int nid;
>
> @@ -1533,6 +1534,10 @@ static int show_numa_map(struct seq_file *m, void *v,
> int is_pid)
> if (!md->pages)
> goto out;
>
> + page_size = vma_kernel_pagesize(vma);
> + if (page_size != PAGE_SIZE)
> + seq_printf(m, " pagesize=%lu", page_size);
It would be simpler to include this unconditionally. Otherwise you
are forcing everybody parsing the file and trying to run calculations
of it to check for its presence, and then have them fall back and get
the value from somewhere else if not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] drivers: char: mem: Fix Missing blank line issues
From: Rob Ward
Fixes "Missing a blank line after declarations" reported by
checkpatch.
This patch introduces no functional changes.
Signed-off-by: Rob Ward
---
drivers/char/mem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index a04ce78..6029d1f 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -575,6 +575,7 @@ static ssize_t write_port(struct file *file, const char
__user *buf,
return -EFAULT;
while (count-- > 0 && i < 65536) {
char c;
+
if (__get_user(c, tmp)) {
if (tmp > buf)
break;
@@ -631,6 +632,7 @@ static ssize_t read_iter_zero(struct kiocb *iocb, struct
iov_iter *iter)
while (iov_iter_count(iter)) {
size_t chunk = iov_iter_count(iter), n;
+
if (chunk > PAGE_SIZE)
chunk = PAGE_SIZE; /* Just for latency reasons */
n = iov_iter_zero(chunk, iter);
--
2.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] drivers: char: mem: Replace usage of asm include
From: Rob Ward Replaces the use of asm/uaccess.h with linux/uaccess.h. Signed-off-by: Rob Ward --- drivers/char/mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/mem.c b/drivers/char/mem.c index 4c58333..a04ce78 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -28,7 +28,7 @@ #include #include -#include +#include #ifdef CONFIG_IA64 # include -- 2.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] checkpatch Warning fixes in drivers/char/mem.c
From: Rob Ward Couple of changes to remove warnings reported by checkpatch.pl within drivers/char/mem.c Neither of these patches introduce functional changes. Rob Ward (2): drivers: char: mem: Replace usage of asm include drivers: char: mem: Fix Missing blank line issues drivers/char/mem.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Fri, Dec 19, 2014 at 5:57 PM, Linus Torvalds wrote: > > I'm claiming that the race happened *once*. And it then corrupted some > data structure or similar sufficiently that CPU0 keeps looping. > > Perhaps something keeps re-adding itself to the head of the timerqueue > due to the race. So tick_sched_timer() does ktime_t now = ktime_get(); ... hrtimer_forward(timer, now, tick_period); return HRTIMER_RESTART; and then __run_hrtimer does enqueue_hrtimer(timer, base); which just adds the timer back on the tiemr heap. So all you need to get an infinite loop (as far as I can see) is that hrtimer_forward() doesn't actually move the timer forward. The most likely reason would seem to be this: delta = ktime_sub(now, hrtimer_get_expires(timer)); if (delta.tv64 < 0) return 0; and clearly it *should* return a positive number, since the timer has expired, so the expiry time _should_ be smaller than "now". So it should never trigger, and this bug is clearly impossible. HOWEVER. It turns out that while tick_sched_timer() does "ktime_get()" to get the current time, the actual timer machinery does *not* do that at all. The actual timer machinery does entry_time = now = hrtimer_update_base(cpu_base); base = cpu_base->clock_base + i; basenow = ktime_add(now, base->offset); _once_ per hrtimer_clock_base. And then it iterates using that "basenow" thing, and compares it to the timer expiry. So we have two different times. Now, let's think about what happens if those clocks aren't quote in sync. We know (since __run_hrtimer was called) that basenow.tv64 > hrtimer_get_softexpires_tv64(timer) but here we have "basenow" - which is not that ktime_get(), and we have "hrtimer_get_softexpires_tv64()" (which is not hrtimer_get_expires() in general - we have all that "delta" range handling, but for the scheduling tick it *should* be the same). So I can see at least one lockup: - if "expires < basenow" hrtimer_interrupt() will run the timer - if "now < expires" hrtimer_forward() will not do anything, and will just reschedule the timer with the same expiration iow, all you need for a re-arming of the same timer is: now < expires < basenow now, the two clocks (now and basenow) are not the same, but they do have the same *base*. So they are related, but even the base time was gotten under two different sequence locks, so even the base could have been updated in between the hrtimer_update_base() time and the ktime_get(). And even though they have the same base, they have different offsets: basenow does that "base->offset" thing (and ktime_get_update_offsets_now() does timekeeping_get_ns() - now = ktime_get() does base = tk->tkr.base_mono; nsecs = timekeeping_get_ns(&tk->tkr); - basenow = ktime_get_update_offsets_now() does base = tk->tkr.base_mono; nsecs = timekeeping_get_ns(&tk->tkr); .. and then .. ktime_add(.., base->offset); and if I read the thing right, the ktime_add() should be a no-op, because base->offset should be 0 for the normal monotonic clock. Right? So the two times (now and basenow) *should* be the same time, and the whole "now < expires < basenow" situation can never happen. Right? Potentially wrong. Because that's where the whole "different sequence locks" comes in. The one-time race could be something that updates the base in between the (one-time) ktime_get_update_offsets_now() and the (then as a result pseudo-infinitely repeating) ktime_get. Hmm? If "base" ever goes backwards, or if "base" does *not* update atomically with the HPET timer overflows, I can see that happening. Of course, that would imply that ktime_get() is not monotonic. But we do know that we've had odd time issues on that machine. I think you already had DaveJ check clock monotonicity. But that was with the TSC, wasn't it? I'm claiming maybe the HPET isn't monotonic, and there is some HPET clocksource issue with overflow in 32 bits. (I think the HPET *should* be 64-bit, and just the comparators for interrupts may be 32-bit, but we use a "readl()" and only use the low 32-bits even if the upper 32 bits *might* be ok). I keep harping on that HPET overflow, because we actually have the 6 "locked up" HPET traces, and then we have a seventh without that lockup, and there definitely was a overflow in 32 bits: [torvalds@i7 linux]$ grep -3 read_hpet+0x16 ~/dj-1.txt | grep RAX RAX: 61fece8a RBX: 00510792 RCX: RAX: 79e588fc RBX: 00511d6e RCX: RAX: 91ca7f65 RBX: 00513346 RCX: RAX: a9afbd0d RBX: 0051491e RCX: RAX: cbd1340c RBX: 0051684a RCX: RAX: fb9d303f RBX: 005193fc RCX: RAX: 2b67efe4 R
Re: [PATCH v2 1/2] i8k: Autodetect maximal fan speed and fan RPM multiplier
On 12/20/2014 09:27 AM, Steven Honeyman wrote: On 20 December 2014 at 17:20, Guenter Roeck wrote: I would think that it should be relatively safe to assume that the first fan always exists That would be a bad idea, as this is definitely not the case: i8k-virtual-0 Adapter: Virtual device fan2:3181 RPM CPU: +43.0°C Ambient: +42.0°C SODIMM: +36.0°C Well, then he'll have to loop through fans until finding one which exists. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: wireless: rtlwifi: rtl8192ee: trx.c: Remove unused function
On 12/20/2014 06:48 AM, Rickard Strandqvist wrote:
Remove the function rtl92ee_get_available_desc() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/net/wireless/rtlwifi/rtl8192ee/trx.c | 21 -
drivers/net/wireless/rtlwifi/rtl8192ee/trx.h |1 -
2 files changed, 22 deletions(-)
Acked-by: Larry Finger
Richard: FYI, John Linville stepped down as wireless maintainer this week, thus
there is no need to send patches to him anymore. Kalle Valo, the new maintainer,
has stated that it is not necessary to Cc him.
Larry
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
index 2fcbef1..8186ed2 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
@@ -710,27 +710,6 @@ static u16 get_desc_addr_fr_q_idx(u16 queue_index)
return desc_address;
}
-void rtl92ee_get_available_desc(struct ieee80211_hw *hw, u8 q_idx)
-{
- struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
- struct rtl_priv *rtlpriv = rtl_priv(hw);
- u16 point_diff = 0;
- u16 current_tx_read_point = 0, current_tx_write_point = 0;
- u32 tmp_4byte;
-
- tmp_4byte = rtl_read_dword(rtlpriv,
- get_desc_addr_fr_q_idx(q_idx));
- current_tx_read_point = (u16)((tmp_4byte >> 16) & 0x0fff);
- current_tx_write_point = (u16)((tmp_4byte) & 0x0fff);
-
- point_diff = ((current_tx_read_point > current_tx_write_point) ?
- (current_tx_read_point - current_tx_write_point) :
- (TX_DESC_NUM_92E - current_tx_write_point +
- current_tx_read_point));
-
- rtlpci->tx_ring[q_idx].avl_desc = point_diff;
-}
-
void rtl92ee_pre_fill_tx_bd_desc(struct ieee80211_hw *hw,
u8 *tx_bd_desc, u8 *desc, u8 queue_index,
struct sk_buff *skb, dma_addr_t addr)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
index 6f9be1c..4426c49 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
@@ -829,7 +829,6 @@ void rtl92ee_rx_check_dma_ok(struct ieee80211_hw *hw, u8
*header_desc,
u8 queue_index);
u16 rtl92ee_rx_desc_buff_remained_cnt(struct ieee80211_hw *hw,
u8 queue_index);
-void rtl92ee_get_available_desc(struct ieee80211_hw *hw, u8 queue_index);
void rtl92ee_pre_fill_tx_bd_desc(struct ieee80211_hw *hw,
u8 *tx_bd_desc, u8 *desc, u8 queue_index,
struct sk_buff *skb, dma_addr_t addr);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.18.1: broken directory with one file too many
On Thu, Dec 18, 2014 at 08:44:37PM +0100, Holger Hoffstätte wrote:
> On 12/18/14 18:06, J. Bruce Fields wrote:
> > Whoops, now I see, the server-side trace has the same problem, I
> > just overlooked it the first time.
>
> Excellent, so we know it's the server's fault. Really would have been odd to
> not have it in the server trace.
>
> >> ..in order to rule out a mistake on my part with the two separate
> >> runs (which prevents correlated analysis) I was just about to boot
> >> the server back into 3.18.1 and re-run both client- and server-side
> >> traces simultaneously. However I have to head out for a bit first;
> >> will post that later today.
> >
> > So this might still be interesting, but it's not a high priority.
>
> Then I guess I'll better keep my feet still and don't muddle the waters
> further, looks like you found what you need. If you still need it just holler.
>
> Let me know if there's anything I can do to help/patch/test!
Gah. Does this fix it?
A struct xdr_stream at a page boundary might point to the end of one
page or the beginning of the next, and I'm guessing xdr_truncate_encode
wasn't prepared to handle the former.
This happens if the readdir entry that would have exceeded the client's
dircount/maxcount limit would have ended exactly on a 4k page boundary,
and inspection of the trace shows you're hitting exactly that case.
If this does the job then I'll go figure out how to make this logic less
ugly
--b.
diff --git a/net/sunrpc/xdr.c b/net/sunrpc/xdr.c
index 1cb61242e55e..32910b91d17c 100644
--- a/net/sunrpc/xdr.c
+++ b/net/sunrpc/xdr.c
@@ -630,6 +630,9 @@ void xdr_truncate_encode(struct xdr_stream *xdr, size_t len)
new = buf->page_base + buf->page_len;
old = new + fraglen;
+ /* XXX: HACK: */
+ if (xdr->p == page_address(*xdr->page_ptr) + PAGE_SIZE)
+ xdr->page_ptr++;
xdr->page_ptr -= (old >> PAGE_SHIFT) - (new >> PAGE_SHIFT);
if (buf->page_len) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: net: ucc: tbi phy detection broken by 058112c7efc9ef43bb511c137293dddbe6e42908
On Sat, Dec 20, 2014 at 09:08:51AM -0800, Florian Fainelli wrote: > There are some comments in ucc_geth that also lead me to believe this > is a just a hack instead of a real Ethernet PHY device. Part of what I > think got broken is because of this comment: > > /* Initialize TBI PHY interface for communicating with the > * SERDES lynx PHY on the chip. We communicate with this PHY > * through the MDIO bus on each controller, treating it as a > * "normal" PHY at the address found in the UTBIPA register. We assume > * that the UTBIPA register is valid. Either the MDIO bus code will set > * it to a value that doesn't conflict with other PHYs on the bus, or the > * value doesn't matter, as there are no other PHYs on the bus. > */ > > In particular this one: > > "Either the MDIO bus code will set > * it to a value that doesn't conflict with other PHYs on the bus, or the > * value doesn't matter, as there are no other PHYs on the bus." > > and what Sebastian removed did exactly that, we used the special MDIO > broadcast address 0 to provide this "whatever". If this is such a > requirement from the ucc_geth driver and TBI PHYs, maybe we should > have this hack somewhere in the actual MDIO driver used by the > ucc_geth driver instead, or set a flag/read the PHY connection mode > and do this in drivers/of/of_mdio.c Well it used to be that it would look for an unused address and assign that, but that was changed to just use 0 unless the dtb specified an address (essentially making specifying the address in the dtb mandetory). Unfortunately after this patch, specifying it in the dtb isn't enough, and the ucc_geth actually hits a null pointer because the tbi phy no longer exists. Before commit 28d8ea2d568534026ccda3e8936f5ea1e04a86a1, the tbi address was in fact _not_ 0. So yes it used to set it to a non conflicting address, but no longer does. It used to pick the highest unused address for the tbi. Now it uses 0 unless the dtb specifies the address. Unfortunately no one ever fixed that comment. It appears to be entirely inaccurate. In the case of the board I am dealing with, setting the address to 0 when it isn't used (port is not in SGMII or RTBI mode) actually breaks things because we have a switch chip at address 0 on the MDIO bus that we now can't reach. Adding explicit addresses for the tbi phy on each ucc solves that though so that is no big deal. The fact that the ucc that needs to actually use the tbi phy for SGMII or RTBI though can't find it anymore because it is no longer created does seem like a problem, and it isn't being created no matter what the address (it is not 0 in this case). So right now it is broken with ucc_geth segfaulting if you use SGMII or RTBI mode. I would love a clean solution to fixing it, although for now reverting this patch has solved the problem. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
