Re: error in `make pdfdocs`

[Markus Heiser]

Am 08.02.2017 um 22:17 schrieb 慕冬亮 :

> Hi all,
> 
> when I `make pdfdocs`, I encountered one error in the following:
> 
> ---
> $ make pdfdocs
> HOSTCC  scripts/basic/fixdep
> HOSTCC  scripts/docproc
> HOSTCC  scripts/check-lc_ctype
> SPHINX  latexdocs --> file:///home/mdl/Repos/linux/Documentation/output/latex
> GENPDF  Documentation/media/uapi/v4l/pipeline.svg
> Segmentation fault

Oops, I guess your toolchain (command 'convert' from ImageMagick) is broken.

-- Markus --


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation: input: fix path to input code definitions

[Martin Kepplinger]

Signed-off-by: Martin Kepplinger 
---
 Documentation/input/input.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/input/input.txt b/Documentation/input/input.txt
index 0acfddb..7ebce10 100644
--- a/Documentation/input/input.txt
+++ b/Documentation/input/input.txt
@@ -279,10 +279,10 @@ struct input_event {
 
   'time' is the timestamp, it returns the time at which the event happened.
 Type is for example EV_REL for relative moment, EV_KEY for a keypress or
-release. More types are defined in include/linux/input.h.
+release. More types are defined in include/uapi/linux/input-event-codes.h.
 
   'code' is event code, for example REL_X or KEY_BACKSPACE, again a complete
-list is in include/linux/input.h.
+list is in include/uapi/linux/input-event-codes.h.
 
   'value' is the value the event carries. Either a relative change for
 EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/10] clocksource/drivers/arm_arch_timer: Remove fsl-a008585 parameter

[Daniel Lezcano]

From: Ding Tianhong 

Having a command line option to flip the errata handling for a
particular erratum is a little bit unusual, and it's vastly superior to
pass this in the DT. By common consensus, it's best to kill off the
command line parameter.

Signed-off-by: Ding Tianhong 
[Mark: split patch, reword commit message]
Signed-off-by: Mark Rutland 
Acked-by: Daniel Lezcano 
Signed-off-by: Daniel Lezcano 
---
 Documentation/admin-guide/kernel-parameters.txt |  9 -
 drivers/clocksource/arm_arch_timer.c| 14 --
 2 files changed, 23 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index be7c0d9..d8fc55a 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -549,15 +549,6 @@
loops can be debugged more effectively on production
systems.
 
-   clocksource.arm_arch_timer.fsl-a008585=
-   [ARM64]
-   Format: 
-   Enable/disable the workaround of Freescale/NXP
-   erratum A-008585.  This can be useful for KVM
-   guests, if the guest device tree doesn't show the
-   erratum.  If unspecified, the workaround is
-   enabled based on the device tree.
-
clearcpuid=BITNUM [X86]
Disable CPUID feature X for the kernel. See
arch/x86/include/asm/cpufeatures.h for the valid bit
diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index 4c8c3fb..6a9d031 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -101,20 +101,6 @@ EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
 
 static int fsl_a008585_enable = -1;
 
-static int __init early_fsl_a008585_cfg(char *buf)
-{
-   int ret;
-   bool val;
-
-   ret = strtobool(buf, );
-   if (ret)
-   return ret;
-
-   fsl_a008585_enable = val;
-   return 0;
-}
-early_param("clocksource.arm_arch_timer.fsl-a008585", early_fsl_a008585_cfg);
-
 u32 __fsl_a008585_read_cntp_tval_el0(void)
 {
return __fsl_a008585_read_reg(cntp_tval_el0);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

[Christopher Covington]

On 02/07/2017 11:05 PM, Timur Tabi wrote:
> Christopher Covington wrote:
>> The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
>> custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
>> BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
>> and 2400v1 SoCs. Checking that the Transmit FIFO Empty (TXFE) bit is 0,
>> instead of checking that the BUSY bit is 1, works around the issue. To
>> facilitate this substitution when UART AMBA Port (UAP) data is available,
>> introduce vendor-specific inversion of Feature Register bits. To keep the
>> change small, this patch only works around the full console case, where UAP
>> data is available, and does not handle the erratum for earlycon, as the UAP
>> data is not available then.

>> +#ifdef CONFIG_QCOM_QDF2400_ERRATUM_44
>> +static struct vendor_data vendor_qdt_qdf2400_e44 = {
>> +.reg_offset= pl011_std_offsets,
>> +.fr_busy= UART011_FR_TXFE,
>> +.fr_dsr= UART01x_FR_DSR,
>> +.fr_cts= UART01x_FR_CTS,
>> +.fr_ri= UART011_FR_RI,
>> +.inv_fr= UART011_FR_TXFE,
>> +.access_32b= true,
>> +.oversampling= false,
>> +.dma_threshold= false,
>> +.cts_event_workaround= false,
>> +.always_enabled= true,
>> +.fixed_options= true,
>> +};
>> +#else
>> +#define vendor_qdt_qdf2400_e44 vendor_sbsa
>> +#endif
> 
> Instead of the #else, just put the #ifdef inside qdf2400_e44(). That
> way, the function always returns False if
> CONFIG_QCOM_QDF2400_ERRATUM_44 is not defined.

I'll consolidate the #ifdefery around qdf2400_e44().

> Also, don't you need to add a definition of .inv_fr in vendor_sbsa
> and the other vendor_xxx structures?

The current struct definitions appear to (ab)use implicit
zero-initialization, so I did too.

>> +
>>  static u16 pl011_st_offsets[REG_ARRAY_SIZE] = {
>>  [REG_DR] = UART01x_DR,
>>  [REG_ST_DMAWM] = ST_UART011_DMAWM,
>> @@ -1518,7 +1538,7 @@ static unsigned int pl011_tx_empty(struct uart_port 
>> *port)
>>  {
>>  struct uart_amba_port *uap =
>>  container_of(port, struct uart_amba_port, port);
>> -unsigned int status = pl011_read(uap, REG_FR);
>> +unsigned int status = pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr;
>>  return status & (uap->vendor->fr_busy | UART01x_FR_TXFF) ?
>>  0 : TIOCSER_TEMT;
>>  }
>> @@ -2218,7 +2238,8 @@ pl011_console_write(struct console *co, const char *s, 
>> unsigned int count)
>>   *Finally, wait for transmitter to become empty
>>   *and restore the TCR
>>   */
>> -while (pl011_read(uap, REG_FR) & uap->vendor->fr_busy)
>> +while ((pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr)
>> +& uap->vendor->fr_busy)
> 
> I really think the XOR logic needs to be documented wherever it's
> used. It's just too confusing.

References such as the following for basic bit operations like
setting, clearing, and toggling are easy enough to come by.

http://stackoverflow.com/questions/47981/how-do-you-set-clear-and-toggle-a-single-bit-in-c-c

Cov

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

[Christopher Covington]

Hi,

On 02/08/2017 08:27 AM, Timur Tabi wrote:
> Robin Murphy wrote:
>> Is there a reason anyone would ever want to turn this off? AFAICS you
>> save a few dozen bytes in return for a kernel image which you know won't
>> work properly on some hardware. That doesn't seem particularly
>> worthwhile, and it's not like the PL011 driver isn't already ripe with
>> unconditional vendor-specific data.

I'll make it unconditional in the next version.

>>> > +static bool qdf2400_e44(void) {
>>> > +u32 cpu_var_model = read_cpuid_id() & ~MIDR_REVISION_MASK;
>>> > +
>>> > +return (cpu_var_model == MIDR_QCOM_KRYO_V1 ||
>>> > +cpu_var_model == MIDR_QCOM_FALKOR_V1);
> 
>> Are we to take it that every SoC now and always with any Kryo or Falkor
>> core which also has an SBSA UART will require this workaround?

I should have matched full 32 bit MIDR values, but I masked off the revision
number after careful investigation of current and future known MIDR values
and system pairings because MIDR_FOO isn't actually a 32 bit MIDR value as
the name would suggest but has variant and revision zeroed. The CPU in the
QDF2432 has a non-zero revision number and I didn't want to try to add an
unprecedented revision number to cputype.h after Will told me I wasn't
allowed to play with CPU toys for SoC games.

I'm going to stop using MIDR, but as an aside, there are two very different
CPUs, which may require different CPU errata workarounds, that (by accident)
only differ by the variant field. Robert Richter's recent MIDR_CPU_VAR_REV
is a welcome clarification.

> No, only Kryo and Falkor V1 based SOCs have this problem. Falkor V2
> will have this fixed.

A year ago, we were operating under the incorrect-in-hindsight assumption
that the QDF2400 v1 SoC with Falkor v1 CPU would have this fixed.

As for alternative means of identifying the errant hardware, I think that I
or a colleague will experiment with the approach used for ACPI PCI quirks:
checking the OEM ID, OEM Table ID, and OEM Revision. In this case, those
header fields would come from the Serial Port Console Redirection (SPCR)
table, rather than the PCI-specific MCFG table.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5b69b85ba1ddd36be01f5c57830b37a3c8256009

Regarding ongoing support, I don't see any disagreement that the code must
be supported and maintained for the life of the hardware, however many years
that ends up being.

Thanks,
Cov

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] time: Remove CONFIG_TIMER_STATS

[Dave Jones]

On Wed, Feb 08, 2017 at 11:54:30AM -0800, Linus Torvalds wrote:
 > On Wed, Feb 8, 2017 at 11:26 AM, Kees Cook  wrote:
 > >
 > > Given that the tracer can give the same information, this patch entirely
 > > removes CONFIG_TIMER_STATS.
 > >
 > > Suggested-by: Thomas Gleixner 
 > > Signed-off-by: Kees Cook 
 > > Acked-by: John Stultz 
 > 
 > Looks good to me. Let's wait for the 4.11 merge window though. I'm
 > assuming I'll get this through the tip timer tree..

>From a quick look at the source, powertop uses this file, and appears to
handle it gracefully if it fails to open, but it will lose functionality
to determine if a timer is deferred.

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

error in `make pdfdocs`

[慕冬亮]

Hi all,

when I `make pdfdocs`, I encountered one error in the following:

---
$ make pdfdocs
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/docproc
  HOSTCC  scripts/check-lc_ctype
  SPHINX  latexdocs --> file:///home/mdl/Repos/linux/Documentation/output/latex
  GENPDF  Documentation/media/uapi/v4l/pipeline.svg
Segmentation fault
Documentation/media/Makefile:42: recipe for target
'Documentation/media/uapi/v4l/pipeline.pdf' failed
make[2]: *** [Documentation/media/uapi/v4l/pipeline.pdf] Error 139
Running Sphinx v1.5.2
WARNING: primary_domain 'C' not found, ignored.
loading pickled environment... not yet created
building [mo]: targets for 0 po files that are out of date
building [latex]: all documents
updating environment: 661 added, 0 changed, 0 removed
./include/linux/init.h:1: warning: no structured comments found
./include/linux/kthread.h:26: warning: Excess function parameter '...'
description in 'kthread_create'
./kernel/sys.c:1: warning: no structured comments found
./drivers/dma-buf/seqno-fence.c:1: warning: no structured comments
found
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'load'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'firstopen'
./include/drm/drm_drv.h:409: warning: No description found for parameter 'open'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'preclose'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'postclose'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'lastclose'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'unload'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'dma_ioctl'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'dma_quiescent'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'context_dtor'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'set_busid'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'irq_handler'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'irq_preinstall'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'irq_postinstall'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'irq_uninstall'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'debugfs_init'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'debugfs_cleanup'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_open_object'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_close_object'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'prime_handle_to_fd'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'prime_fd_to_handle'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_prime_export'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_prime_import'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_prime_pin'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_prime_unpin'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_prime_res_obj'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_prime_get_sg_table'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_prime_import_sg_table'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_prime_vmap'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_prime_vunmap'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_prime_mmap'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'vgaarb_irq'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'gem_vm_ops'
./include/drm/drm_drv.h:409: warning: No description found for parameter 'major'
./include/drm/drm_drv.h:409: warning: No description found for parameter 'minor'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'patchlevel'
./include/drm/drm_drv.h:409: warning: No description found for parameter 'name'
./include/drm/drm_drv.h:409: warning: No description found for parameter 'desc'
./include/drm/drm_drv.h:409: warning: No description found for parameter 'date'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'driver_features'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'dev_priv_size'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'ioctls'
./include/drm/drm_drv.h:409: warning: No description found for
parameter 'num_ioctls'
./include/drm/drm_drv.h:409: 

[PATCH v7] arm64: Work around Falkor erratum 1003

[Christopher Covington]

The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
is triggered, page table entries using the new translation table base
address (BADDR) will be allocated into the TLB using the old ASID. All
circumstances leading to the incorrect ASID being cached in the TLB arise
when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
operation is in the process of performing a translation using the specific
TTBRx_EL1 being written, and the memory operation uses a translation table
descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
ASID is not subject to this erratum because hardware is prohibited from
performing translations from an out-of-context translation regime.

Consider the following pseudo code.

  write new BADDR and ASID values to TTBRx_EL1

Replacing the above sequence with the one below will ensure that no TLB
entries with an incorrect ASID are used by software.

  write reserved value to TTBRx_EL1[ASID]
  ISB
  write new value to TTBRx_EL1[BADDR]
  ISB
  write new value to TTBRx_EL1[ASID]
  ISB

When the above sequence is used, page table entries using the new BADDR
value may still be incorrectly allocated into the TLB using the reserved
ASID. Yet this will not reduce functionality, since TLB entries incorrectly
tagged with the reserved ASID will never be hit by a later instruction.

Based on work by Shanker Donthineni 

Signed-off-by: Christopher Covington 
---
 Documentation/arm64/silicon-errata.txt |  1 +
 arch/arm64/Kconfig | 18 ++
 arch/arm64/include/asm/assembler.h | 23 +++
 arch/arm64/include/asm/cpucaps.h   |  3 ++-
 arch/arm64/include/asm/mmu_context.h   |  8 +++-
 arch/arm64/kernel/cpu_errata.c |  9 +
 arch/arm64/mm/context.c| 11 +++
 arch/arm64/mm/proc.S   |  1 +
 8 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/Documentation/arm64/silicon-errata.txt 
b/Documentation/arm64/silicon-errata.txt
index 0006a94c2321..50da8391e9dd 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -63,4 +63,5 @@ stable kernels.
 | Cavium | ThunderX SMMUv2 | #27704  | N/A|
 || | | 
|
 | Freescale/NXP  | LS2080A/LS1043A | A-008585| FSL_ERRATUM_A008585 
|
+| Qualcomm Tech. | Falkor v1   | E1003   | 
QCOM_FALKOR_ERRATUM_1003|
 | Qualcomm Tech. | Falkor v1   | E1009   | 
QCOM_FALKOR_ERRATUM_1009|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index f45405664558..d2fe685b9026 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -480,6 +480,24 @@ config CAVIUM_ERRATUM_27456
 
  If unsure, say Y.
 
+config QCOM_FALKOR_ERRATUM_1003
+   bool "Falkor E1003: Incorrect translation due to ASID change"
+   default y
+   select ARM64_PAN if ARM64_SW_TTBR0_PAN
+   help
+ On Falkor v1, an incorrect ASID may be cached in the TLB when ASID
+ and BADDR are changed together in TTBRx_EL1. The workaround for this
+ issue is to use a reserved ASID in cpu_do_switch_mm() before
+ switching to the new ASID. Saying Y here selects ARM64_PAN if
+ ARM64_SW_TTBR0_PAN is selected. This is done because implementing and
+ maintaining the E1003 workaround in the software PAN emulation code
+ would be an unnecessary complication. The affected Falkor v1 CPU
+ implements ARMv8.1 hardware PAN support and using hardware PAN
+ support versus software PAN emulation is mutually exclusive at
+ runtime.
+
+ If unsure, say Y.
+
 config QCOM_FALKOR_ERRATUM_1009
bool "Falkor E1009: Prematurely complete a DSB after a TLBI"
default y
diff --git a/arch/arm64/include/asm/assembler.h 
b/arch/arm64/include/asm/assembler.h
index 446f6c46d4b1..33b20c075fb3 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -423,6 +424,28 @@ alternative_endif
.endm
 
 /*
+ * Errata workaround prior to TTBR0_EL1 update
+ *
+ * val:TTBR value with new BADDR, preserved
+ * tmp0:   temporary register, clobbered
+ * tmp1:   other temporary register, clobbered
+ */
+   .macro  pre_ttbr0_update_workaround, val, tmp0, tmp1
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
+alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
+   mrs \tmp0, ttbr0_el1
+   mov \tmp1, #FALKOR_RESERVED_ASID
+   bfi \tmp0, \tmp1, #48, #16  // reserved ASID + old BADDR
+   msr ttbr0_el1, \tmp0
+   isb
+   bfi \tmp0, \val, #0, #48// reserved ASID + new BADDR
+   msr ttbr0_el1, 

Re: [PATCH v2] time: Remove CONFIG_TIMER_STATS

[Linus Torvalds]

On Wed, Feb 8, 2017 at 11:26 AM, Kees Cook  wrote:
>
> Given that the tracer can give the same information, this patch entirely
> removes CONFIG_TIMER_STATS.
>
> Suggested-by: Thomas Gleixner 
> Signed-off-by: Kees Cook 
> Acked-by: John Stultz 

Looks good to me. Let's wait for the 4.11 merge window though. I'm
assuming I'll get this through the tip timer tree..

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] time: Remove CONFIG_TIMER_STATS

[Kees Cook]

Currently CONFIG_TIMER_STATS exposes process information across namespaces:

kernel/time/timer_list.c print_timer():

SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);

/proc/timer_list:

 #11: <>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570

Given that the tracer can give the same information, this patch entirely
removes CONFIG_TIMER_STATS.

Suggested-by: Thomas Gleixner 
Signed-off-by: Kees Cook 
Acked-by: John Stultz 
---
v2:
- dropped doc comments for removed structure elements; thx 0-day builder.
---
 Documentation/timers/timer_stats.txt |  73 --
 include/linux/hrtimer.h  |  11 -
 include/linux/timer.h|  45 
 kernel/kthread.c |   1 -
 kernel/time/Makefile |   1 -
 kernel/time/hrtimer.c|  38 
 kernel/time/timer.c  |  48 +---
 kernel/time/timer_list.c |  10 -
 kernel/time/timer_stats.c| 425 ---
 kernel/workqueue.c   |   2 -
 lib/Kconfig.debug|  14 --
 11 files changed, 2 insertions(+), 666 deletions(-)
 delete mode 100644 Documentation/timers/timer_stats.txt
 delete mode 100644 kernel/time/timer_stats.c

diff --git a/Documentation/timers/timer_stats.txt 
b/Documentation/timers/timer_stats.txt
deleted file mode 100644
index de835ee97455..
--- a/Documentation/timers/timer_stats.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-timer_stats - timer usage statistics
-
-
-timer_stats is a debugging facility to make the timer (ab)usage in a Linux
-system visible to kernel and userspace developers. If enabled in the config
-but not used it has almost zero runtime overhead, and a relatively small
-data structure overhead. Even if collection is enabled runtime all the
-locking is per-CPU and lookup is hashed.
-
-timer_stats should be used by kernel and userspace developers to verify that
-their code does not make unduly use of timers. This helps to avoid unnecessary
-wakeups, which should be avoided to optimize power consumption.
-
-It can be enabled by CONFIG_TIMER_STATS in the "Kernel hacking" configuration
-section.
-
-timer_stats collects information about the timer events which are fired in a
-Linux system over a sample period:
-
-- the pid of the task(process) which initialized the timer
-- the name of the process which initialized the timer
-- the function where the timer was initialized
-- the callback function which is associated to the timer
-- the number of events (callbacks)
-
-timer_stats adds an entry to /proc: /proc/timer_stats
-
-This entry is used to control the statistics functionality and to read out the
-sampled information.
-
-The timer_stats functionality is inactive on bootup.
-
-To activate a sample period issue:
-# echo 1 >/proc/timer_stats
-
-To stop a sample period issue:
-# echo 0 >/proc/timer_stats
-
-The statistics can be retrieved by:
-# cat /proc/timer_stats
-
-While sampling is enabled, each readout from /proc/timer_stats will see
-newly updated statistics. Once sampling is disabled, the sampled information
-is kept until a new sample period is started. This allows multiple readouts.
-
-Sample output of /proc/timer_stats:
-
-Timerstats sample period: 3.888770 s
-  12, 0 swapper  hrtimer_stop_sched_tick (hrtimer_sched_tick)
-  15, 1 swapper  hcd_submit_urb (rh_timer_func)
-   4,   959 kedacschedule_timeout (process_timeout)
-   1, 0 swapper  page_writeback_init (wb_timer_fn)
-  28, 0 swapper  hrtimer_stop_sched_tick (hrtimer_sched_tick)
-  22,  2948 IRQ 4tty_flip_buffer_push (delayed_work_timer_fn)
-   3,  3100 bash schedule_timeout (process_timeout)
-   1, 1 swapper  queue_delayed_work_on (delayed_work_timer_fn)
-   1, 1 swapper  queue_delayed_work_on (delayed_work_timer_fn)
-   1, 1 swapper  neigh_table_init_no_netlink (neigh_periodic_timer)
-   1,  2292 ip   __netdev_watchdog_up (dev_watchdog)
-   1,23 events/1 do_cache_clean (delayed_work_timer_fn)
-90 total events, 30.0 events/sec
-
-The first column is the number of events, the second column the pid, the third
-column is the name of the process. The forth column shows the function which
-initialized the timer and in parenthesis the callback function which was
-executed on expiry.
-
-Thomas, Ingo
-
-Added flag to indicate 'deferrable timer' in /proc/timer_stats. A deferrable
-timer will appear as follows
-  10D, 1 swapper  queue_delayed_work_on (delayed_work_timer_fn)
-
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index cdab81ba29f8..e52b427223ba 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -88,12 +88,6 @@ enum hrtimer_restart {
  * @base:  pointer to the timer base (per cpu and per clock)
  * @state:   

Re: [PATCH] time: Remove CONFIG_TIMER_STATS

[John Stultz]

On Wed, Feb 8, 2017 at 2:24 AM, Thomas Gleixner  wrote:
> On Tue, 7 Feb 2017, John Stultz wrote:
>> On Tue, Feb 7, 2017 at 3:40 PM, Kees Cook  wrote:
>> > Currently CONFIG_TIMER_STATS exposes process information across namespaces:
>> >
>> > kernel/time/timer_list.c print_timer():
>> >
>> > SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);
>> >
>> > /proc/timer_list:
>> >
>> >  #11: <>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570
>> >
>> > Given that the tracer can give the same information, this patch entirely
>> > removes CONFIG_TIMER_STATS.
>> >
>> > Suggested-by: Thomas Gleixner 
>> > Signed-off-by: Kees Cook 
>>
>> I don't have an issue with this, but I worry this would break some
>> tooling out there. Should it be marked as deprecated first?
>>
>> Or maybe just pulling the band-aid off is the best way?
>
> I think we should just kill it.
>
> No tools can really rely on the behaviour of that file because it depends
> on CONFIG_TIMER_STATS and the information available there is just a random
> snapshot of queued timers at a given point of time, which is in no way
> usefull.

Fair enough.

Acked-by: John Stultz 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drm/doc: Add TODO list

[Thierry Reding]

On Tue, Feb 07, 2017 at 08:01:37PM +0100, Daniel Vetter wrote:
> On Tue, Feb 07, 2017 at 06:51:13PM +0100, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > This commit adds a TODO list to the GPU driver developer's guide. The
> > content was taken from the DRMJanitors page on the X.Org wiki:
> > 
> > https://www.x.org/wiki/DRMJanitors/
> > 
> > The goal is to track a list of refactorings that would be nice to see
> > merged eventually. Sometimes these would be encountered during patch
> > review on the mailing list, and at other times one can come across
> > these while working in a specific area of code.
> > 
> > Signed-off-by: Thierry Reding 
> 
> Sean also acked this on irc, merged to drm-misc-next. I'll update the wiki
> with the link. And I assume you'll follow up with a patch, cc: Noralf,
> with the tinydrm cleanups once that landed?

Yes, will do.

Thanks,
Thierry


signature.asc
Description: PGP signature

Re: [PATCH v6] arm64: Work around Falkor erratum 1003

[Catalin Marinas]

On Tue, Feb 07, 2017 at 07:35:16PM -0500, Christopher Covington wrote:
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -480,6 +480,18 @@ config CAVIUM_ERRATUM_27456
>  
> If unsure, say Y.
>  
> +config QCOM_FALKOR_ERRATUM_1003
> + bool "Falkor E1003: Incorrect translation due to ASID change"
> + default y
> + select ARM64_PAN if ARM64_SW_TTBR0_PAN
> + help
> +   On Falkor v1, an incorrect ASID may be cached in the TLB when ASID
> +   and BADDR are changed together in TTBRx_EL1. The workaround for this
> +   issue is to use a reserved ASID in cpu_do_switch_mm() before
> +   switching to the new ASID.
> +
> +   If unsure, say Y.

It would be good to have a comment here on why PAN is selected.

> --- a/arch/arm64/mm/context.c
> +++ b/arch/arm64/mm/context.c
> @@ -79,6 +79,13 @@ void verify_cpu_asid_bits(void)
>   }
>  }
>  
> +static void set_reserved_asid_bits(void)
> +{
> + if (IS_ENABLED(CONFIG_QCOM_FALKOR_ERRATUM_1003) &&
> + cpus_have_cap(ARM64_WORKAROUND_QCOM_FALKOR_E1003))
> + __set_bit(FALKOR_RESERVED_ASID, asid_map);
> +}

You should use cpus_have_const_cap() as it would be optimised using jump
labels.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 09/10] dt-bindings: mux-adg792a: document devicetree bindings for ADG792A/G mux

[Peter Rosin]

Analog Devices ADG792A/G is a triple 4:1 mux.

Acked-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 .../devicetree/bindings/mux/adi,adg792a.txt| 75 ++
 1 file changed, 75 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mux/adi,adg792a.txt

diff --git a/Documentation/devicetree/bindings/mux/adi,adg792a.txt 
b/Documentation/devicetree/bindings/mux/adi,adg792a.txt
new file mode 100644
index ..96b787a69f50
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/adi,adg792a.txt
@@ -0,0 +1,75 @@
+Bindings for Analog Devices ADG792A/G Triple 4:1 Multiplexers
+
+Required properties:
+- compatible : "adi,adg792a" or "adi,adg792g"
+- #mux-control-cells : <0> if parallel (the three muxes are bound together
+  with a single mux controller controlling all three muxes), or <1> if
+  not (one mux controller for each mux).
+* Standard mux-controller bindings as described in mux-controller.txt
+
+Optional properties for ADG792G:
+- gpio-controller : if present, #gpio-cells below is required.
+- #gpio-cells : should be <2>
+ - First cell is the GPO line number, i.e. 0 or 1
+ - Second cell is used to specify active high (0)
+   or active low (1)
+
+Optional properties:
+- idle-state : if present, array of states that the mux controllers will have
+  when idle. The special state MUX_IDLE_AS_IS is the default and
+  MUX_IDLE_DISCONNECT is also supported.
+
+States 0 through 3 correspond to signals A through D in the datasheet.
+
+Example:
+
+   /*
+* Three independent mux controllers (of which one is used).
+* Mux 0 is disconnected when idle, mux 1 idles in the previously
+* selected state and mux 2 idles with signal B.
+*/
+{
+   mux: mux-controller@50 {
+   compatible = "adi,adg792a";
+   reg = <0x50>;
+   #mux-control-cells = <1>;
+
+   idle-state = ;
+   };
+   };
+
+   adc-mux {
+   compatible = "io-channel-mux";
+   io-channels = < 0>;
+   io-channel-names = "parent";
+
+   mux-controls = < 2>;
+
+   channels = "sync-1", "", "out";
+   };
+
+
+   /*
+* Three parallel muxes with one mux controller, useful e.g. if
+* the adc is differential, thus needing two signals to be muxed
+* simultaneously for correct operation.
+*/
+{
+   pmux: mux-controller@50 {
+   compatible = "adi,adg792a";
+   reg = <0x50>;
+   #mux-control-cells = <0>;
+
+   idle-state = <1>;
+   };
+   };
+
+   diff-adc-mux {
+   compatible = "io-channel-mux";
+   io-channels = < 0>;
+   io-channel-names = "parent";
+
+   mux-controls = <>;
+
+   channels = "sync-1", "", "out";
+   };
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 04/10] iio: inkern: api for manipulating ext_info of iio channels

[Peter Rosin]

Extend the inkern api with functions for reading and writing ext_info
of iio channels.

Acked-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 drivers/iio/inkern.c | 60 
 include/linux/iio/consumer.h | 37 +++
 2 files changed, 97 insertions(+)

diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 7a13535dc3e9..8292ad4435ea 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -869,3 +869,63 @@ int iio_write_channel_raw(struct iio_channel *chan, int 
val)
return ret;
 }
 EXPORT_SYMBOL_GPL(iio_write_channel_raw);
+
+unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan)
+{
+   const struct iio_chan_spec_ext_info *ext_info;
+   unsigned int i = 0;
+
+   if (!chan->channel->ext_info)
+   return i;
+
+   for (ext_info = chan->channel->ext_info; ext_info->name; ext_info++)
+   ++i;
+
+   return i;
+}
+EXPORT_SYMBOL_GPL(iio_get_channel_ext_info_count);
+
+static const struct iio_chan_spec_ext_info *iio_lookup_ext_info(
+   const struct iio_channel *chan,
+   const char *attr)
+{
+   const struct iio_chan_spec_ext_info *ext_info;
+
+   if (!chan->channel->ext_info)
+   return NULL;
+
+   for (ext_info = chan->channel->ext_info; ext_info->name; ++ext_info) {
+   if (!strcmp(attr, ext_info->name))
+   return ext_info;
+   }
+
+   return NULL;
+}
+
+ssize_t iio_read_channel_ext_info(struct iio_channel *chan,
+ const char *attr, char *buf)
+{
+   const struct iio_chan_spec_ext_info *ext_info;
+
+   ext_info = iio_lookup_ext_info(chan, attr);
+   if (!ext_info)
+   return -EINVAL;
+
+   return ext_info->read(chan->indio_dev, ext_info->private,
+ chan->channel, buf);
+}
+EXPORT_SYMBOL_GPL(iio_read_channel_ext_info);
+
+ssize_t iio_write_channel_ext_info(struct iio_channel *chan, const char *attr,
+  const char *buf, size_t len)
+{
+   const struct iio_chan_spec_ext_info *ext_info;
+
+   ext_info = iio_lookup_ext_info(chan, attr);
+   if (!ext_info)
+   return -EINVAL;
+
+   return ext_info->write(chan->indio_dev, ext_info->private,
+  chan->channel, buf, len);
+}
+EXPORT_SYMBOL_GPL(iio_write_channel_ext_info);
diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
index 47eeec3218b5..5e347a9805fd 100644
--- a/include/linux/iio/consumer.h
+++ b/include/linux/iio/consumer.h
@@ -312,4 +312,41 @@ int iio_read_channel_scale(struct iio_channel *chan, int 
*val,
 int iio_convert_raw_to_processed(struct iio_channel *chan, int raw,
int *processed, unsigned int scale);
 
+/**
+ * iio_get_channel_ext_info_count() - get number of ext_info attributes
+ *   connected to the channel.
+ * @chan:  The channel being queried
+ *
+ * Returns the number of ext_info attributes
+ */
+unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan);
+
+/**
+ * iio_read_channel_ext_info() - read ext_info attribute from a given channel
+ * @chan:  The channel being queried.
+ * @attr:  The ext_info attribute to read.
+ * @buf:   Where to store the attribute value. Assumed to hold
+ * at least PAGE_SIZE bytes.
+ *
+ * Returns the number of bytes written to buf (perhaps w/o zero termination;
+ * it need not even be a string), or an error code.
+ */
+ssize_t iio_read_channel_ext_info(struct iio_channel *chan,
+ const char *attr, char *buf);
+
+/**
+ * iio_write_channel_ext_info() - write ext_info attribute from a given channel
+ * @chan:  The channel being queried.
+ * @attr:  The ext_info attribute to read.
+ * @buf:   The new attribute value. Strings needs to be zero-
+ * terminated, but the terminator should not be included
+ * in the below len.
+ * @len:   The size of the new attribute value.
+ *
+ * Returns the number of accepted bytes, which should be the same as len.
+ * An error code can also be returned.
+ */
+ssize_t iio_write_channel_ext_info(struct iio_channel *chan, const char *attr,
+  const char *buf, size_t len);
+
 #endif
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

[Timur Tabi]

On 02/08/2017 09:35 AM, Marc Zyngier wrote:

Interesting. How will you guarantee that nobody will ever want to run a
mainline kernel on this box after a certain date? Self-destruct timer?
;-)

As someone who runs mainline on HW that exceeded its "sell-by" date by a
few decades, I'm genuinely interested.


The affected chips are pre-production and are only available to select 
customers for a limited time.


--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 10/10] mux: adg792a: add mux controller driver for ADG792A/G

[Peter Rosin]

Analog Devices ADG792A/G is a triple 4:1 mux.

Reviewed-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 drivers/mux/Kconfig   |  12 
 drivers/mux/Makefile  |   1 +
 drivers/mux/mux-adg792a.c | 140 ++
 3 files changed, 153 insertions(+)
 create mode 100644 drivers/mux/mux-adg792a.c

diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 57e6f4e5fda9..d13fcf98958e 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -16,6 +16,18 @@ menuconfig MULTIPLEXER
 
 if MULTIPLEXER
 
+config MUX_ADG792A
+   tristate "Analog Devices ADG792A/ADG792G Multiplexers"
+   depends on I2C
+   help
+ ADG792A and ADG792G Wide Bandwidth Triple 4:1 Multiplexers
+
+ The driver supports both operating the three multiplexers in
+ parallel and operating them independently.
+
+ To compile the driver as a module, choose M here: the module will
+ be called mux-adg792a.
+
 config MUX_GPIO
tristate "GPIO-controlled Multiplexer"
depends on OF && GPIOLIB
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index facc43da3648..fddbb073fc77 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -3,4 +3,5 @@
 #
 
 obj-$(CONFIG_MULTIPLEXER)  += mux-core.o
+obj-$(CONFIG_MUX_ADG792A)  += mux-adg792a.o
 obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
diff --git a/drivers/mux/mux-adg792a.c b/drivers/mux/mux-adg792a.c
new file mode 100644
index ..d58971641fdc
--- /dev/null
+++ b/drivers/mux/mux-adg792a.c
@@ -0,0 +1,140 @@
+/*
+ * Multiplexer driver for Analog Devices ADG792A/G Triple 4:1 mux
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define ADG792A_LDSW   BIT(0)
+#define ADG792A_RESET  BIT(1)
+#define ADG792A_DISABLE(mux)   (0x50 | (mux))
+#define ADG792A_DISABLE_ALL(0x5f)
+#define ADG792A_MUX(mux, state)(0xc0 | (((mux) + 1) << 2) | (state))
+#define ADG792A_MUX_ALL(state) (0xc0 | (state))
+
+static int adg792a_set(struct mux_control *mux, int state)
+{
+   struct i2c_client *i2c = to_i2c_client(mux->chip->dev.parent);
+   u8 cmd;
+
+   if (mux->chip->controllers == 1) {
+   /* parallel mux controller operation */
+   if (state == MUX_IDLE_DISCONNECT)
+   cmd = ADG792A_DISABLE_ALL;
+   else
+   cmd = ADG792A_MUX_ALL(state);
+   } else {
+   unsigned int controller = mux_control_get_index(mux);
+
+   if (state == MUX_IDLE_DISCONNECT)
+   cmd = ADG792A_DISABLE(controller);
+   else
+   cmd = ADG792A_MUX(controller, state);
+   }
+
+   return i2c_smbus_write_byte_data(i2c, cmd, ADG792A_LDSW);
+}
+
+static const struct mux_control_ops adg792a_ops = {
+   .set = adg792a_set,
+};
+
+static int adg792a_probe(struct i2c_client *i2c,
+const struct i2c_device_id *id)
+{
+   struct device *dev = >dev;
+   struct mux_chip *mux_chip;
+   u32 cells;
+   int ret;
+   int i;
+
+   ret = of_property_read_u32(dev->of_node, "#mux-control-cells", );
+   if (ret < 0)
+   return ret;
+   if (cells >= 2)
+   return -EINVAL;
+
+   mux_chip = devm_mux_chip_alloc(dev, cells ? 3 : 1, 0);
+   if (!mux_chip)
+   return -ENOMEM;
+
+   mux_chip->ops = _ops;
+
+   ret = i2c_smbus_write_byte_data(i2c, ADG792A_DISABLE_ALL,
+   ADG792A_RESET | ADG792A_LDSW);
+   if (ret < 0)
+   return ret;
+
+   for (i = 0; i < mux_chip->controllers; ++i) {
+   struct mux_control *mux = _chip->mux[i];
+   s32 idle_state;
+
+   mux->states = 4;
+
+   ret = of_property_read_u32_index(dev->of_node, "idle-state", i,
+(s32 *)_state);
+   if (ret < 0)
+   continue;
+
+   switch (idle_state) {
+   case 0 ... 4:
+   case MUX_IDLE_DISCONNECT:
+   mux_chip->mux[i].idle_state = idle_state;
+   break;
+   case MUX_IDLE_AS_IS:
+   break;
+   default:
+   dev_err(dev, "invalid idle-state %d\n", idle_state);
+   return -EINVAL;
+   }
+   }
+
+   ret = devm_mux_chip_register(dev, mux_chip);
+   if (ret < 0)
+   return ret;
+
+   if (cells)
+   dev_info(dev, "3x single pole quadruple throw muxes 

[PATCH v9 07/10] dt-bindings: i2c: i2c-mux: document general purpose i2c-mux bindings

[Peter Rosin]

Describe how a general purpose multiplexer controller is used to mux an
i2c bus.

Acked-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 .../devicetree/bindings/i2c/i2c-mux-gpmux.txt  | 99 ++
 1 file changed, 99 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt
new file mode 100644
index ..2907dab56298
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt
@@ -0,0 +1,99 @@
+General Purpose I2C Bus Mux
+
+This binding describes an I2C bus multiplexer that uses a mux controller
+from the mux subsystem to route the I2C signals.
+
+  .-.  .-.
+  | dev |  | dev |
+..'-'  '-'
+| SoC|   ||
+||  .+'
+|   .--. |  .--+child bus A, on MUX value set to 0
+|   | I2C  |-|--| Mux  |
+|   '--' |  '--+---+child bus B, on MUX value set to 1
+|   .--. | |'--++.
+|   | MUX- | | |   |||
+|   | Ctrl |-|-+.-.  .-.  .-.
+|   '--' |  | dev |  | dev |  | dev |
+''  '-'  '-'  '-'
+
+Required properties:
+- compatible: i2c-mux
+- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
+  port is connected to.
+- mux-controls: The phandle of the mux controller to use for operating the
+  mux.
+* Standard I2C mux properties. See i2c-mux.txt in this directory.
+* I2C child bus nodes. See i2c-mux.txt in this directory. The sub-bus number
+  is also the mux-controller state described in ../mux/mux-controller.txt
+
+Optional properties:
+- mux-locked: If present, explicitly allow unrelated I2C transactions on the
+  parent I2C adapter at these times:
+   + during setup of the multiplexer
+   + between setup of the multiplexer and the child bus I2C transaction
+   + between the child bus I2C transaction and releasing of the multiplexer
+   + during releasing of the multiplexer
+  However, I2C transactions to devices behind all I2C multiplexers connected
+  to the same parent adapter that this multiplexer is connected to are blocked
+  for the full duration of the complete multiplexed I2C transaction (i.e.
+  including the times covered by the above list).
+  If mux-locked is not present, the multiplexer is assumed to be parent-locked.
+  This means that no unrelated I2C transactions are allowed on the parent I2C
+  adapter for the complete multiplexed I2C transaction.
+  The properties of mux-locked and parent-locked multiplexers are discussed
+  in more detail in Documentation/i2c/i2c-topology.
+
+For each i2c child node, an I2C child bus will be created. They will
+be numbered based on their order in the device tree.
+
+Whenever an access is made to a device on a child bus, the value set
+in the relevant node's reg property will be set as the state in the
+mux controller.
+
+Example:
+   mux: mux-controller {
+   compatible = "gpio-mux";
+   #mux-control-cells = <0>;
+
+   mux-gpios = < 0 GPIO_ACTIVE_HIGH>,
+   < 1 GPIO_ACTIVE_HIGH>;
+   };
+
+   i2c-mux {
+   compatible = "i2c-mux";
+   mux-locked;
+   i2c-parent = <>;
+
+   mux-controls = <>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   i2c@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ssd1307: oled@3c {
+   compatible = "solomon,ssd1307fb-i2c";
+   reg = <0x3c>;
+   pwms = < 4 3000>;
+   reset-gpios = < 7 1>;
+   reset-active-low;
+   };
+   };
+
+   i2c@3 {
+   reg = <3>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pca9555: pca9555@20 {
+   compatible = "nxp,pca9555";
+   gpio-controller;
+   #gpio-cells = <2>;
+   reg = <0x20>;
+   };
+   };
+   };
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 08/10] i2c: i2c-mux-gpmux: new driver

[Peter Rosin]

This is a general purpose i2c mux that uses a multiplexer controlled by
the multiplexer subsystem to do the muxing.

The user can select if the mux is to be mux-locked and parent-locked
as described in Documentation/i2c/i2c-topology.

Acked-by: Jonathan Cameron 
Acked-by: Wolfram Sang 
Signed-off-by: Peter Rosin 
---
 drivers/i2c/muxes/Kconfig |  13 +++
 drivers/i2c/muxes/Makefile|   1 +
 drivers/i2c/muxes/i2c-mux-gpmux.c | 173 ++
 3 files changed, 187 insertions(+)
 create mode 100644 drivers/i2c/muxes/i2c-mux-gpmux.c

diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 10b3d17ae3ea..5fb34f24 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -30,6 +30,19 @@ config I2C_MUX_GPIO
  This driver can also be built as a module.  If so, the module
  will be called i2c-mux-gpio.
 
+config I2C_MUX_GPMUX
+   tristate "General Purpose I2C multiplexer"
+   select MULTIPLEXER
+   depends on OF
+   help
+ If you say yes to this option, support will be included for a
+ general purpose I2C multiplexer. This driver provides access to
+ I2C busses connected through a MUX, which in turn is controlled
+ by a MUX-controller from the MUX subsystem.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-mux-gpmux.
+
 config I2C_MUX_PCA9541
tristate "NXP PCA9541 I2C Master Selector"
help
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 9948fa45037f..af43c6c3e861 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE)+= 
i2c-arb-gpio-challenge.o
 obj-$(CONFIG_I2C_DEMUX_PINCTRL)+= i2c-demux-pinctrl.o
 
 obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
+obj-$(CONFIG_I2C_MUX_GPMUX)+= i2c-mux-gpmux.o
 obj-$(CONFIG_I2C_MUX_MLXCPLD)  += i2c-mux-mlxcpld.o
 obj-$(CONFIG_I2C_MUX_PCA9541)  += i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)  += i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-mux-gpmux.c 
b/drivers/i2c/muxes/i2c-mux-gpmux.c
new file mode 100644
index ..fb23b2278462
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-mux-gpmux.c
@@ -0,0 +1,173 @@
+/*
+ * General Purpose I2C multiplexer
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct mux {
+   struct mux_control *control;
+
+   bool do_not_deselect;
+};
+
+static int i2c_mux_select(struct i2c_mux_core *muxc, u32 chan)
+{
+   struct mux *mux = i2c_mux_priv(muxc);
+   int ret;
+
+   ret = mux_control_select(mux->control, chan);
+   mux->do_not_deselect = ret < 0;
+
+   return ret;
+}
+
+static int i2c_mux_deselect(struct i2c_mux_core *muxc, u32 chan)
+{
+   struct mux *mux = i2c_mux_priv(muxc);
+
+   if (mux->do_not_deselect)
+   return 0;
+
+   return mux_control_deselect(mux->control);
+}
+
+static struct i2c_adapter *mux_parent_adapter(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct device_node *parent_np;
+   struct i2c_adapter *parent;
+
+   parent_np = of_parse_phandle(np, "i2c-parent", 0);
+   if (!parent_np) {
+   dev_err(dev, "Cannot parse i2c-parent\n");
+   return ERR_PTR(-ENODEV);
+   }
+   parent = of_find_i2c_adapter_by_node(parent_np);
+   of_node_put(parent_np);
+   if (!parent)
+   return ERR_PTR(-EPROBE_DEFER);
+
+   return parent;
+}
+
+static const struct of_device_id i2c_mux_of_match[] = {
+   { .compatible = "i2c-mux", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, i2c_mux_of_match);
+
+static int i2c_mux_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
+   struct device_node *child;
+   struct i2c_mux_core *muxc;
+   struct mux *mux;
+   struct i2c_adapter *parent;
+   int children;
+   int ret;
+
+   if (!np)
+   return -ENODEV;
+
+   mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL);
+   if (!mux)
+   return -ENOMEM;
+
+   mux->control = devm_mux_control_get(dev, NULL);
+   if (IS_ERR(mux->control)) {
+   if (PTR_ERR(mux->control) != -EPROBE_DEFER)
+   dev_err(dev, "failed to get control-mux\n");
+   return PTR_ERR(mux->control);
+   }
+
+   parent = mux_parent_adapter(dev);
+   if (IS_ERR(parent)) {
+   if (PTR_ERR(parent) != -EPROBE_DEFER)
+   

[PATCH v9 05/10] dt-bindings: iio: io-channel-mux: document io-channel-mux bindings

[Peter Rosin]

Describe how a multiplexer can be used to select which signal is fed to
an io-channel.

Acked-by: Jonathan Cameron 
Acked-by: Rob Herring 
Signed-off-by: Peter Rosin 
---
 .../bindings/iio/multiplexer/io-channel-mux.txt| 39 ++
 MAINTAINERS|  6 
 2 files changed, 45 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt

diff --git 
a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt 
b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
new file mode 100644
index ..c82794002595
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
@@ -0,0 +1,39 @@
+I/O channel multiplexer bindings
+
+If a multiplexer is used to select which hardware signal is fed to
+e.g. an ADC channel, these bindings describe that situation.
+
+Required properties:
+- compatible : "io-channel-mux"
+- io-channels : Channel node of the parent channel that has multiplexed
+   input.
+- io-channel-names : Should be "parent".
+- #address-cells = <1>;
+- #size-cells = <0>;
+- mux-controls : Mux controller node to use for operating the mux
+- channels : List of strings, labeling the mux controller states.
+
+For each non-empty string in the channels property, an io-channel will
+be created. The number of this io-channel is the same as the index into
+the list of strings in the channels property, and also matches the mux
+controller state. The mux controller state is described in
+../mux/mux-controller.txt
+
+Example:
+   mux: mux-controller {
+   compatible = "mux-gpio";
+   #mux-control-cells = <0>;
+
+   mux-gpios = < 0 GPIO_ACTIVE_HIGH>,
+   < 1 GPIO_ACTIVE_HIGH>;
+   };
+
+   adc-mux {
+   compatible = "io-channel-mux";
+   io-channels = < 0>;
+   io-channel-names = "parent";
+
+   mux-controls = <>;
+
+   channels = "sync", "in", "system-regulator";
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 353fa1f37a40..3d572d446320 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6313,6 +6313,12 @@ F:   
Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
 F: Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
 F: drivers/iio/adc/envelope-detector.c
 
+IIO MULTIPLEXER
+M: Peter Rosin 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
+
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
 R: Hartmut Knaack 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 06/10] iio: multiplexer: new iio category and iio-mux driver

[Peter Rosin]

When a multiplexer changes how an iio device behaves (for example
by feeding different signals to an ADC), this driver can be used
to create one virtual iio channel for each multiplexer state.

Depends on the generic multiplexer subsystem.

Cache any ext_info values from the parent iio channel, creating a private
copy of the ext_info attributes for each multiplexer state/channel.

Reviewed-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 MAINTAINERS   |   1 +
 drivers/iio/Kconfig   |   1 +
 drivers/iio/Makefile  |   1 +
 drivers/iio/multiplexer/Kconfig   |  18 ++
 drivers/iio/multiplexer/Makefile  |   6 +
 drivers/iio/multiplexer/iio-mux.c | 456 ++
 6 files changed, 483 insertions(+)
 create mode 100644 drivers/iio/multiplexer/Kconfig
 create mode 100644 drivers/iio/multiplexer/Makefile
 create mode 100644 drivers/iio/multiplexer/iio-mux.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 3d572d446320..4cb4e5d0c3b1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6318,6 +6318,7 @@ M:Peter Rosin 
 L: linux-...@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
+F: drivers/iio/multiplexer/iio-mux.c
 
 IIO SUBSYSTEM AND DRIVERS
 M: Jonathan Cameron 
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index a918270d6f54..b3c8c6ef0dff 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -83,6 +83,7 @@ source "drivers/iio/humidity/Kconfig"
 source "drivers/iio/imu/Kconfig"
 source "drivers/iio/light/Kconfig"
 source "drivers/iio/magnetometer/Kconfig"
+source "drivers/iio/multiplexer/Kconfig"
 source "drivers/iio/orientation/Kconfig"
 if IIO_TRIGGER
source "drivers/iio/trigger/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 33fa4026f92c..93c769cd99bf 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -28,6 +28,7 @@ obj-y += humidity/
 obj-y += imu/
 obj-y += light/
 obj-y += magnetometer/
+obj-y += multiplexer/
 obj-y += orientation/
 obj-y += potentiometer/
 obj-y += potentiostat/
diff --git a/drivers/iio/multiplexer/Kconfig b/drivers/iio/multiplexer/Kconfig
new file mode 100644
index ..70a044510686
--- /dev/null
+++ b/drivers/iio/multiplexer/Kconfig
@@ -0,0 +1,18 @@
+#
+# Multiplexer drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Multiplexers"
+
+config IIO_MUX
+   tristate "IIO multiplexer driver"
+   select MULTIPLEXER
+   depends on OF
+   help
+ Say yes here to build support for the IIO multiplexer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-mux.
+
+endmenu
diff --git a/drivers/iio/multiplexer/Makefile b/drivers/iio/multiplexer/Makefile
new file mode 100644
index ..68be3c4abd07
--- /dev/null
+++ b/drivers/iio/multiplexer/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for industrial I/O multiplexer drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_MUX) += iio-mux.o
diff --git a/drivers/iio/multiplexer/iio-mux.c 
b/drivers/iio/multiplexer/iio-mux.c
new file mode 100644
index ..94d40f9bef4c
--- /dev/null
+++ b/drivers/iio/multiplexer/iio-mux.c
@@ -0,0 +1,456 @@
+/*
+ * IIO multiplexer driver
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct mux_ext_info_cache {
+   char *data;
+   size_t size;
+};
+
+struct mux_child {
+   struct mux_ext_info_cache *ext_info_cache;
+};
+
+struct mux {
+   int cached_state;
+   struct mux_control *control;
+   struct iio_channel *parent;
+   struct iio_dev *indio_dev;
+   struct iio_chan_spec *chan;
+   struct iio_chan_spec_ext_info *ext_info;
+   struct mux_child *child;
+};
+
+static int iio_mux_select(struct mux *mux, int idx)
+{
+   struct mux_child *child = >child[idx];
+   struct iio_chan_spec const *chan = >chan[idx];
+   int ret;
+   int i;
+
+   ret = mux_control_select(mux->control, chan->channel);
+   if (ret < 0) {
+   mux->cached_state = -1;
+   return ret;
+   }
+
+   if (mux->cached_state == chan->channel)
+   return 0;
+
+   if (chan->ext_info) {
+   for (i = 0; chan->ext_info[i].name; ++i) {
+   const char *attr = chan->ext_info[i].name;
+   struct mux_ext_info_cache *cache;
+
+   cache = >ext_info_cache[i];
+
+   if (cache->size < 0)
+ 

Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

[Marc Zyngier]

On Wed, Feb 08 2017 at  2:09:12 pm GMT, Timur Tabi  wrote:
> Mark Rutland wrote:
>
>>> No, only Kryo and Falkor V1 based SOCs have this problem.  Falkor V2
>>> will have this fixed.  We intend to revert these fixes after Falkor
>>> V1 SOCs are no longer supported.
>>
>> Supported by whom?
>
> Qualcomm.
>
>> Generally, once something's upstreamed we expect it to remain supported.
>
> The V1 SOCs are technically pre-production, but still in wide use and
> it will be a while before they are all replaced by V2 SOCs.  It's only
> because of the "ugliness" of the erratum and its work-around that we
> want to git rid of it when we can.

Interesting. How will you guarantee that nobody will ever want to run a
mainline kernel on this box after a certain date? Self-destruct timer?
;-)

As someone who runs mainline on HW that exceeded its "sell-by" date by a
few decades, I'm genuinely interested.

Thanks,

M.
-- 
Jazz is not dead, it just smell funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 02/10] dt-bindings: document devicetree bindings for mux-controllers and gpio-mux

[Peter Rosin]

Allow specifying that a single multiplexer controller can be used to
control several parallel multiplexers, thus enabling sharing of the
multiplexer controller by different consumers.

Add a binding for a first mux controller in the form of a GPIO based mux
controller.

Acked-by: Jonathan Cameron 
Acked-by: Rob Herring 
Signed-off-by: Peter Rosin 
---
 Documentation/devicetree/bindings/mux/gpio-mux.txt |  69 +
 .../devicetree/bindings/mux/mux-controller.txt | 157 +
 MAINTAINERS|   6 +
 include/dt-bindings/mux/mux.h  |  16 +++
 4 files changed, 248 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mux/gpio-mux.txt
 create mode 100644 Documentation/devicetree/bindings/mux/mux-controller.txt
 create mode 100644 include/dt-bindings/mux/mux.h

diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.txt 
b/Documentation/devicetree/bindings/mux/gpio-mux.txt
new file mode 100644
index ..b8f746344d80
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/gpio-mux.txt
@@ -0,0 +1,69 @@
+GPIO-based multiplexer controller bindings
+
+Define what GPIO pins are used to control a multiplexer. Or several
+multiplexers, if the same pins control more than one multiplexer.
+
+Required properties:
+- compatible : "gpio-mux"
+- mux-gpios : list of gpios used to control the multiplexer, least
+ significant bit first.
+- #mux-control-cells : <0>
+* Standard mux-controller bindings as decribed in mux-controller.txt
+
+Optional properties:
+- idle-state : if present, the state the mux will have when idle. The
+  special state MUX_IDLE_AS_IS is the default.
+
+The multiplexer state is defined as the number represented by the
+multiplexer GPIO pins, where the first pin is the least significant
+bit. An active pin is a binary 1, an inactive pin is a binary 0.
+
+Example:
+
+   mux: mux-controller {
+   compatible = "gpio-mux";
+   #mux-control-cells = <0>;
+
+   mux-gpios = < 0 GPIO_ACTIVE_HIGH>,
+   < 1 GPIO_ACTIVE_HIGH>;
+   };
+
+   adc-mux {
+   compatible = "io-channel-mux";
+   io-channels = < 0>;
+   io-channel-names = "parent";
+
+   mux-controls = <>;
+
+   channels = "sync-1", "in", "out", "sync-2";
+   };
+
+   i2c-mux {
+   compatible = "i2c-mux";
+   i2c-parent = <>;
+
+   mux-controls = <>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   i2c@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ssd1307: oled@3c {
+   /* ... */
+   };
+   };
+
+   i2c@3 {
+   reg = <3>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pca9555: pca9555@20 {
+   /* ... */
+   };
+   };
+   };
diff --git a/Documentation/devicetree/bindings/mux/mux-controller.txt 
b/Documentation/devicetree/bindings/mux/mux-controller.txt
new file mode 100644
index ..4f47e4bd2fa0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/mux-controller.txt
@@ -0,0 +1,157 @@
+Common multiplexer controller bindings
+==
+
+A multiplexer (or mux) controller will have one, or several, consumer devices
+that uses the mux controller. Thus, a mux controller can possibly control
+several parallel multiplexers. Presumably there will be at least one
+multiplexer needed by each consumer, but a single mux controller can of course
+control several multiplexers for a single consumer.
+
+A mux controller provides a number of states to its consumers, and the state
+space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer,
+0-7 for an 8-way multiplexer, etc.
+
+
+Consumers
+-
+
+Mux controller consumers should specify a list of mux controllers that they
+want to use with a property containing a 'mux-ctrl-list':
+
+   mux-ctrl-list ::=  [mux-ctrl-list]
+   single-mux-ctrl ::=  [mux-ctrl-specifier]
+   mux-ctrl-phandle : phandle to mux controller node
+   mux-ctrl-specifier : array of #mux-control-cells specifying the
+given mux controller (controller specific)
+
+Mux controller properties should be named "mux-controls". The exact meaning of
+each mux controller property must be documented in the device tree binding for
+each consumer. An optional property "mux-control-names" may contain a list of
+strings to label each of the mux controllers listed in the "mux-controls"
+property.
+
+Drivers for devices that use more than a 

[PATCH v9 03/10] mux: minimal mux subsystem and gpio-based mux controller

[Peter Rosin]

Add a new minimalistic subsystem that handles multiplexer controllers.
When multiplexers are used in various places in the kernel, and the
same multiplexer controller can be used for several independent things,
there should be one place to implement support for said multiplexer
controller.

A single multiplexer controller can also be used to control several
parallel multiplexers, that are in turn used by different subsystems
in the kernel, leading to a need to coordinate multiplexer accesses.
The multiplexer subsystem handles this coordination.

This new mux controller subsystem initially comes with a single backend
driver that controls gpio based multiplexers. Even though not needed by
this initial driver, the mux controller subsystem is prepared to handle
chips with multiple (independent) mux controllers.

Reviewed-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 Documentation/driver-model/devres.txt |   8 +
 MAINTAINERS   |   2 +
 drivers/Kconfig   |   2 +
 drivers/Makefile  |   1 +
 drivers/mux/Kconfig   |  33 +++
 drivers/mux/Makefile  |   6 +
 drivers/mux/mux-core.c| 414 ++
 drivers/mux/mux-gpio.c| 114 ++
 include/linux/mux.h   | 248 
 9 files changed, 828 insertions(+)
 create mode 100644 drivers/mux/Kconfig
 create mode 100644 drivers/mux/Makefile
 create mode 100644 drivers/mux/mux-core.c
 create mode 100644 drivers/mux/mux-gpio.c
 create mode 100644 include/linux/mux.h

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index dc51fb024190..1e9ae701a587 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -332,6 +332,14 @@ MEM
 MFD
   devm_mfd_add_devices()
 
+MUX
+  devm_mux_chip_alloc()
+  devm_mux_chip_free()
+  devm_mux_chip_register()
+  devm_mux_chip_unregister()
+  devm_mux_control_get()
+  devm_mux_control_put()
+
 PER-CPU MEM
   devm_alloc_percpu()
   devm_free_percpu()
diff --git a/MAINTAINERS b/MAINTAINERS
index 8a0adb1e6194..353fa1f37a40 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8500,6 +8500,8 @@ M:Peter Rosin 
 S: Maintained
 F: Documentation/devicetree/bindings/mux/
 F: include/linux/dt-bindings/mux/
+F: include/linux/mux.h
+F: drivers/mux/
 
 MULTISOUND SOUND DRIVER
 M: Andrew Veliath 
diff --git a/drivers/Kconfig b/drivers/Kconfig
index e1e2066cecdb..ea231018089e 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -202,4 +202,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
 
 source "drivers/fpga/Kconfig"
 
+source "drivers/mux/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 060026a02f59..8ff0460bb2f8 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -173,3 +173,4 @@ obj-$(CONFIG_STM)   += hwtracing/stm/
 obj-$(CONFIG_ANDROID)  += android/
 obj-$(CONFIG_NVMEM)+= nvmem/
 obj-$(CONFIG_FPGA) += fpga/
+obj-$(CONFIG_MULTIPLEXER)  += mux/
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
new file mode 100644
index ..57e6f4e5fda9
--- /dev/null
+++ b/drivers/mux/Kconfig
@@ -0,0 +1,33 @@
+#
+# Multiplexer devices
+#
+
+menuconfig MULTIPLEXER
+   bool "Multiplexer subsystem"
+   help
+ Multiplexer controller subsystem. Multiplexers are used in a
+ variety of settings, and this subsystem abstracts their use
+ so that the rest of the kernel sees a common interface. When
+ multiple parallel multiplexers are controlled by one single
+ multiplexer controller, this subsystem also coordinates the
+ multiplexer accesses.
+
+ If unsure, say no.
+
+if MULTIPLEXER
+
+config MUX_GPIO
+   tristate "GPIO-controlled Multiplexer"
+   depends on OF && GPIOLIB
+   help
+ GPIO-controlled Multiplexer controller.
+
+ The driver builds a single multiplexer controller using a number
+ of gpio pins. For N pins, there will be 2^N possible multiplexer
+ states. The GPIO pins can be connected (by the hardware) to several
+ multiplexers, which in that case will be operated in parallel.
+
+ To compile the driver as a module, choose M here: the module will
+ be called mux-gpio.
+
+endif
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
new file mode 100644
index ..facc43da3648
--- /dev/null
+++ b/drivers/mux/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for multiplexer devices.
+#
+
+obj-$(CONFIG_MULTIPLEXER)  += mux-core.o
+obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
new file mode 100644
index ..46088a0f9677
--- /dev/null
+++ b/drivers/mux/mux-core.c
@@ -0,0 +1,414 @@
+/*
+ * Multiplexer subsystem
+ *

[PATCH v9 00/10] mux controller abstraction and iio/i2c muxes

[Peter Rosin]

Hi!

v8 -> v9 changes
- dropped the suffix from the compatible string of the i2c-mux-simple
  binding (was ,mux-locked or ,parent-locked) and add an optional
  mux-locked property instead to change the desired locking behavior
  from the default parent-locked
- add description of the difference between mux-locked and parent-locked
- renamed i2c-mux-simple to i2c-mux (bindings for this general purpose
  i2c mux are in i2c-mux-gpmux.txt since i2c-mux.txt is already occupied
  by the common i2c-mux bindings)
- changed compatible from mux-gpio to gpio-mux
- changed bindings for idle-state back to a single array, but add defines
  for as-is and hi-Z thus avoiding magic numbers
- make use of the above defines in the code as well
- make idle-state a common mux property described in mux-controller.txt
  instead of repeating the info in individual mux controller bindings
- drop the adi,parallel property from the adg792 bindings and piggy-back
  on the #mux-control-cells property
- refrain from using the compatible string as node name
- dropped the simplified bindings for single-user gpio mux
- added acks on patches 2/10 and 5/10 from Rob

v7 -> v8 changes
- cleanup the implementation of the simplified gpio bindings, but still...
- ...reorder patches so that they appear last in the series (patches 11
  and 12 were patches 4 and 5 in v7) since Jonathan convinced me that
  they were perhaps not such a good idea after all. But I still wanted
  to show the last version I had and I'm still a bit undecided...
- added some words to the remaining otherwise empty commit messages
- added various acks/reviews from Jonathan and Wolfram.
- move mux last in drivers/Kconfig and drivers/Makefile
- bump copyright years
- centralize error reporting of common operatinons to the mux core
- add WARN_ON for faulty usage of mux_chip_register
- simplify code for other WARN_ON call sites

v6 -> v7 changes
- move from drivers/misc/mux-* to drivers/mux/
  [I will remove Cc:s to Arnd and Greg for v8, when/if that happens]
- add managed versions of mux_chip_alloc and mux_chip_register
- use the above in mux-gpio.c and mux-adg792a.c
- also use them to support a simplified binding of a gpio mux for the common
  case where there is a single consumer (and no specific idle requirements)
- new binding for describing idle behaviour of mux-adg792a
- add bindings for the gpo-pins on the mux-adg792g
- use device_property_read_u32 instead of of_property_read_u32 in mux-gpio.c
- rename iio mux compatible to io-channel-mux (was iio-mux)
- remove linuxism in the bindings (it was mentioning a function name)
- add missing quote in the example in the io-channel-mux binding
- factor out preparatory cleanup of devres docs to its own patch
- add blank line in mux_chip_free
- use SIMPLE_{PARENT,MUX}_LOCKED instead of magic numbers {0,1} in
  i2c-mux-simple.c
- add some acks and a reviewed-by from Jonathan

v5 -> v6 changes
- fix stupidity in mux_chip_priv, mux_gpio_remove and adg792a_remove.
- change the devicetree bindings for the iio-mux to use a list of strings
  (channels property) instead of a list children.

v4 -> v5 changes
- remove support for fancier dt layouts and go back to the phandle
  approach from v2 and before, killing the horrible non-working
  refcounting crap from v4 and avoiding a bunch of life-time issues
  in v3.
- introduce the concept of a mux-chip, that can hold one or more
  mux-controllers (inspired by the pwm subsystem).
- add dt #mux-control-cells property needed to get to the desired
  mux controller if a mux chip provides more than one.
- take away the option to build the mux-core as a module.
- if the mux controller has an idle state, make sure the mux controller
  is set up in the idle state initially (when it should be idle).
- do not use a variable length array on the stack in mux_gpio_set to
  temporarily store the gpio state, preallocate space instead.
- fix resource leak on one failure path in mux_gpio_probe.
- driver for Analog Devices ADG792A/G, literally the first mux chip
  I found on the Internet with an i2c interface (that was not a
  dedicated i2c multiplexer like PCA9547) which I used to verify
  that the abstractions in the mux core are up to the task. Untested,
  just proof of concept that at least looks pretty and compiles...
- various touch-ups.

v3 -> v4 changes
- rebased onto next-20161122 (depends on recent _available iio changes).
- added support for having the mux-controller in a child node of a
  mux-consumer if it is a sole consumer, to hopefully even further satisfy
  the complaint from Rob (and later Lars-Peter) about dt complexity.
- the above came at the cost of some rather horrible refcounting code,
  please review and suggest how it should be done...
- changed to register a device class instead of a bus.
- pass in the parent device into mux_control_alloc and require less
  work from mux-control drivers.
- changed device names from mux:control%d to mux%d
- move kernel-doc from mux-core.c to mux.h (and 

[PATCH v9 01/10] devres: trivial whitespace fix

[Peter Rosin]

Everything else is indented with two spaces, so fix the odd one out.

Acked-by: Jonathan Cameron 
Signed-off-by: Peter Rosin 
---
 Documentation/driver-model/devres.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index ca9d1eb46bc0..dc51fb024190 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -330,7 +330,7 @@ MEM
   devm_kzalloc()
 
 MFD
- devm_mfd_add_devices()
+  devm_mfd_add_devices()
 
 PER-CPU MEM
   devm_alloc_percpu()
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

[Timur Tabi]

Mark Rutland wrote:


No, only Kryo and Falkor V1 based SOCs have this problem.  Falkor V2
will have this fixed.  We intend to revert these fixes after Falkor
V1 SOCs are no longer supported.


Supported by whom?


Qualcomm.


Generally, once something's upstreamed we expect it to remain supported.


The V1 SOCs are technically pre-production, but still in wide use and it will be 
a while before they are all replaced by V2 SOCs.  It's only because of the 
"ugliness" of the erratum and its work-around that we want to git rid of it when 
we can.


Cov is better equipped to answer your other questions.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

[Mark Rutland]

On Wed, Feb 08, 2017 at 07:27:29AM -0600, Timur Tabi wrote:
> Robin Murphy wrote:

> >Are we to take it that every SoC now and always with any Kryo or Falkor
> >core which also has an SBSA UART will require this workaround?
> 
> No, only Kryo and Falkor V1 based SOCs have this problem.  Falkor V2
> will have this fixed.  We intend to revert these fixes after Falkor
> V1 SOCs are no longer supported.

Supported by whom?

Generally, once something's upstreamed we expect it to remain supported.

> > There's a
> >guarantee that the UART itself will definitely never be fixed in some
> >future revision? That it'll never be integrated into, say, some
> >Kryo/Cortex-Axx big.LITTLE system where you do still need the
> >workaround, but might be making this check on the wrong core?
> 
> We are sure that this erratum is restricted to those specific SOCs.

Ok. Then please identify the system as a whole (i.e. the SoC), and not
the CPU.

> >If there's really no suitable ID register to identify this particular
> >UART implementation, it probably needs to be described appropriately by
> >the firmware - I can't claim knowledge of how that works under ACPI, but
> >I do note that the only device ID currently being matched is "ARMH0011",
> >which seems to me to be inappropriate to describe something which is not
> >an ARM PL011, bugs or no bugs.
> 
> ACPI is not like device tree.  You can't just define a
> "qcom,needs-busy-bit-fix" property and call it a day.

ACPI and DT have pretty much the exact same set of issues w.r.t.
long term maintenance and support.

The important step is raising issues early, rather than shipping FW with
values that are not known to work (or known to not work)...

> If you're saying that we should create a new ACPI HID, like
> QCOM0011, that probably would have worked as well, except hindsight
> is 20/20, and we already have firmware in the field.

There are other way of identifying the system, if you look further than
the device.

Thanks,
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

[Timur Tabi]

Robin Murphy wrote:

Is there a reason anyone would ever want to turn this off? AFAICS you
save a few dozen bytes in return for a kernel image which you know won't
work properly on some hardware. That doesn't seem particularly
worthwhile, and it's not like the PL011 driver isn't already ripe with
unconditional vendor-specific data.


> +
>  config SERIAL_EARLYCON_ARM_SEMIHOST
>bool "Early console using ARM semihosting"
>depends on ARM64 || ARM
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index d4171d71a258..41e51901d6ef 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -97,6 +97,7 @@ struct vendor_data {
>unsigned intfr_dsr;
>unsigned intfr_cts;
>unsigned intfr_ri;
> +  unsigned intinv_fr;
>boolaccess_32b;
>booloversampling;
>booldma_threshold;
> @@ -141,6 +142,25 @@ static struct vendor_data vendor_sbsa = {
>.fixed_options  = true,
>  };
>
> +#ifdef CONFIG_QCOM_QDF2400_ERRATUM_44
> +static struct vendor_data vendor_qdt_qdf2400_e44 = {
> +  .reg_offset = pl011_std_offsets,
> +  .fr_busy= UART011_FR_TXFE,
> +  .fr_dsr = UART01x_FR_DSR,
> +  .fr_cts = UART01x_FR_CTS,
> +  .fr_ri  = UART011_FR_RI,
> +  .inv_fr = UART011_FR_TXFE,
> +  .access_32b = true,
> +  .oversampling   = false,
> +  .dma_threshold  = false,
> +  .cts_event_workaround   = false,
> +  .always_enabled = true,
> +  .fixed_options  = true,
> +};
> +#else
> +#define vendor_qdt_qdf2400_e44 vendor_sbsa
> +#endif
> +
>  static u16 pl011_st_offsets[REG_ARRAY_SIZE] = {
>[REG_DR] = UART01x_DR,
>[REG_ST_DMAWM] = ST_UART011_DMAWM,
> @@ -1518,7 +1538,7 @@ static unsigned int pl011_tx_empty(struct uart_port 
*port)
>  {
>struct uart_amba_port *uap =
>container_of(port, struct uart_amba_port, port);
> -  unsigned int status = pl011_read(uap, REG_FR);
> +  unsigned int status = pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr;
>return status & (uap->vendor->fr_busy | UART01x_FR_TXFF) ?
>0 : TIOCSER_TEMT;
>  }
> @@ -2218,7 +2238,8 @@ pl011_console_write(struct console *co, const char *s, 
unsigned int count)
> *  Finally, wait for transmitter to become empty
> *  and restore the TCR
> */
> -  while (pl011_read(uap, REG_FR) & uap->vendor->fr_busy)
> +  while ((pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr)
> +  & uap->vendor->fr_busy)
>cpu_relax();
>if (!uap->vendor->always_enabled)
>pl011_write(old_cr, uap, REG_CR);
> @@ -2383,6 +2404,13 @@ static struct console amba_console = {
>
>  #define AMBA_CONSOLE  (_console)
>
> +static bool qdf2400_e44(void) {
> +  u32 cpu_var_model = read_cpuid_id() & ~MIDR_REVISION_MASK;
> +
> +  return (cpu_var_model == MIDR_QCOM_KRYO_V1 ||
> +  cpu_var_model == MIDR_QCOM_FALKOR_V1);



Are we to take it that every SoC now and always with any Kryo or Falkor
core which also has an SBSA UART will require this workaround?


No, only Kryo and Falkor V1 based SOCs have this problem.  Falkor V2 will have 
this fixed.  We intend to revert these fixes after Falkor V1 SOCs are no longer 
supported.


> There's a

guarantee that the UART itself will definitely never be fixed in some
future revision? That it'll never be integrated into, say, some
Kryo/Cortex-Axx big.LITTLE system where you do still need the
workaround, but might be making this check on the wrong core?


We are sure that this erratum is restricted to those specific SOCs.



If there's really no suitable ID register to identify this particular
UART implementation, it probably needs to be described appropriately by
the firmware - I can't claim knowledge of how that works under ACPI, but
I do note that the only device ID currently being matched is "ARMH0011",
which seems to me to be inappropriate to describe something which is not
an ARM PL011, bugs or no bugs.


ACPI is not like device tree.  You can't just define a "qcom,needs-busy-bit-fix" 
property and call it a day.


If you're saying that we should create a new ACPI HID, like QCOM0011, that 
probably would have worked as well, except hindsight is 20/20, and we already 
have firmware in the field.


--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

[Robin Murphy]

On 08/02/17 00:57, Christopher Covington wrote:
> The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
> custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
> BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
> and 2400v1 SoCs. Checking that the Transmit FIFO Empty (TXFE) bit is 0,
> instead of checking that the BUSY bit is 1, works around the issue. To
> facilitate this substitution when UART AMBA Port (UAP) data is available,
> introduce vendor-specific inversion of Feature Register bits. To keep the
> change small, this patch only works around the full console case, where UAP
> data is available, and does not handle the erratum for earlycon, as the UAP
> data is not available then.
> 
> Signed-off-by: Christopher Covington 
> Acked-by: Russell King 
> ---
> Changes between the previous RFC [1] and this PATCH:
> * don't use arch/arm64/kernel/cpu_errata.c at Will's request
> * separate out earlycon case to separate patch
> * rework earlycon case to not depend on UAP as suggested by Timur
> 
> Because they need a newly-defined MIDR values, the patches are currently
> based on:
> https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=for-next/core
> 
> I'm not confident that I know the best route for these two patches. Should
> I request Catalin and Will to take them via arm64 as the essential MIDR
> additions are their purview?
> 
> Thanks Russell for the ack. Compared to the RFC, I've made minor changes to
> what is now patch 1/2 and am making an educated guess that the ack sticks
> (but if not please let me know). Patch 2/2 is significantly revised from
> the RFC so I've not included the ack on it.
> 
> 1. https://patchwork.codeaurora.org/patch/163281/
> ---
>  Documentation/arm64/silicon-errata.txt |  2 ++
>  arch/arm64/include/asm/cputype.h   |  2 ++
>  drivers/tty/serial/Kconfig | 12 ++
>  drivers/tty/serial/amba-pl011.c| 40 
> +++---
>  4 files changed, 53 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/arm64/silicon-errata.txt 
> b/Documentation/arm64/silicon-errata.txt
> index 50da8391e9dd..0993ebb3e86b 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -65,3 +65,5 @@ stable kernels.
>  | Freescale/NXP  | LS2080A/LS1043A | A-008585| FSL_ERRATUM_A008585   
>   |
>  | Qualcomm Tech. | Falkor v1   | E1003   | 
> QCOM_FALKOR_ERRATUM_1003|
>  | Qualcomm Tech. | Falkor v1   | E1009   | 
> QCOM_FALKOR_ERRATUM_1009|
> +| Qualcomm Tech. | QDF2432v1 UART  | SoC E44 | 
> QCOM_QDF2400_ERRATUM_44 |
> +| Qualcomm Tech. | QDF2400v1 UART  | SoC E44 | 
> QCOM_QDF2400_ERRATUM_44 |
> diff --git a/arch/arm64/include/asm/cputype.h 
> b/arch/arm64/include/asm/cputype.h
> index fc502713ab37..cb399c7fe6ec 100644
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@ -88,12 +88,14 @@
>  
>  #define BRCM_CPU_PART_VULCAN 0x516
>  
> +#define QCOM_CPU_PART_KRYO_V10x281
>  #define QCOM_CPU_PART_FALKOR_V1  0x800
>  
>  #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
> ARM_CPU_PART_CORTEX_A53)
>  #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
> ARM_CPU_PART_CORTEX_A57)
>  #define MIDR_THUNDERXMIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
> CAVIUM_CPU_PART_THUNDERX)
>  #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
> CAVIUM_CPU_PART_THUNDERX_81XX)
> +#define MIDR_QCOM_KRYO_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, 
> QCOM_CPU_PART_KRYO_V1)
>  #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, 
> QCOM_CPU_PART_FALKOR_V1)
>  
>  #ifndef __ASSEMBLY__
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index e9cf5b67f1b7..4cde8f48a540 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -73,6 +73,18 @@ config SERIAL_AMBA_PL011_CONSOLE
> your boot loader (lilo or loadlin) about how to pass options to the
> kernel at boot time.)
>  
> +config QCOM_QDF2400_ERRATUM_44
> + bool "Work around QDF2400 SoC E44 stuck BUSY bit"
> + depends on SERIAL_AMBA_PL011_CONSOLE=y
> + default y
> + help
> +   The BUSY bit in the Flag Register of the UART on the QDF2432v1 and
> +   QDF2400v1 SoCs may get stuck as 1, resulting in a hung serial console.
> +   Say Y here to work around the issue by checking TXFE == 0 instead of
> +   BUSY == 1 on affected systems.
> +
> +   If unsure, say Y.

Is there a reason anyone would ever want to turn this off? AFAICS you
save a few dozen bytes in return for a kernel image which you know won't
work properly on some hardware. That doesn't seem particularly
worthwhile, and it's not like the PL011 driver isn't already ripe with
unconditional vendor-specific data.

> +
>  config SERIAL_EARLYCON_ARM_SEMIHOST
>   bool 

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

[Jesper Dangaard Brouer]

On Tue, 7 Feb 2017 14:23:23 -0700
Jonathan Corbet  wrote:

> On Tue, 7 Feb 2017 21:51:49 +0100
> Jesper Dangaard Brouer  wrote:
> 
> > I sounds like Daniel (see other email) have bigger plans for what
> > Documentation/BPF/ should contain.  E.g. consolidating
> > Documentation/networking/filter.txt which covers the cBPF/eBPF internals.
> > If that is the case (and I like the idea), then it goes beyond a
> > "userspace-guide".  And perhaps "BPF" is a "book" of its own?  
> 
> One of the real problems with the kernel's documentation is that there is
> really almost no thought given to who the audience is.  We have docs for
> kernel developers, for system admins, for user-space developers, etc., and
> it's all mixed up into one big jumble.
> 
> An objective of mine in launching into this whole project is to try to fix
> that, so that people can readily find the documentation they need.  So I
> don't think a single top-level directory, with a mix of user-space API
> info and "internals", is the right direction to go.  The internals docs
> should, IMO, go elsewhere, probably in the core-api manual.
> 
> See what I'm getting at here?

First I was reluctant (as it would be "easier" just to cramp every eBPF
thing into one directory).  Thinking more about, I agree with you, and
I like your vision.  Focus on the target audience and avoid mixing
different target audience in the same document/book is the way forward.

My audience and objective is helping developers getting started using
eBPF, not core-developers on eBPF (like Daniel).  I do see that, if we
start mixing in too much "internals" then we loose sense of the
original target audience, and then they "exit" as they get "lost" in
details that does not concern them.

Separating BPF docs into different directories (or "books") will make
us think about the target audience.

I would like to propose directory structure:

 Documentation/user-guide/bpf/
 Documentation/core-api/bpf/


> > And it seems Daniel is proposing capital-letters BPF for the directory
> > name "Documentation/BPF/"?  Any opinions on that? (I'm neutral)  
> 
> I think we should paint it green; otherwise I'm not too concerned about
> this particular point...:)

True, bikeshedding...

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] time: Remove CONFIG_TIMER_STATS

[Thomas Gleixner]

On Tue, 7 Feb 2017, John Stultz wrote:
> On Tue, Feb 7, 2017 at 3:40 PM, Kees Cook  wrote:
> > Currently CONFIG_TIMER_STATS exposes process information across namespaces:
> >
> > kernel/time/timer_list.c print_timer():
> >
> > SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);
> >
> > /proc/timer_list:
> >
> >  #11: <>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570
> >
> > Given that the tracer can give the same information, this patch entirely
> > removes CONFIG_TIMER_STATS.
> >
> > Suggested-by: Thomas Gleixner 
> > Signed-off-by: Kees Cook 
> 
> I don't have an issue with this, but I worry this would break some
> tooling out there. Should it be marked as deprecated first?
> 
> Or maybe just pulling the band-aid off is the best way?

I think we should just kill it.

No tools can really rely on the behaviour of that file because it depends
on CONFIG_TIMER_STATS and the information available there is just a random
snapshot of queued timers at a given point of time, which is in no way
usefull.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] kconfig/mconf: add jumping tip in title of search result textbox

[Jani Nikula]

On Wed, 08 Feb 2017, changbin...@intel.com wrote:
> From: Changbin Du 
>
> Prompt user how to quickly jump to the item he/she is interested in.
>
> Signed-off-by: Changbin Du 
> Reviewed-by: Jani Nikula 

This is assuming too much... but I looked at it now, and it looks good
to me.

Thanks,
Jani.

> ---
>  scripts/kconfig/mconf.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
> index 315ce2c..23d5681 100644
> --- a/scripts/kconfig/mconf.c
> +++ b/scripts/kconfig/mconf.c
> @@ -443,10 +443,10 @@ static void search_conf(void)
>  
>   res = get_relations_str(sym_arr, );
>   set_subtitle();
> - dres = show_textbox_ext(_("Search Results"), (char *)
> - str_get(), 0, 0, keys, ,
> - , _text, (void *)
> - );
> + dres = show_textbox_ext(
> + _("Search Results (type the number to jump)"),
> + (char *)str_get(), 0, 0, keys, ,
> + , _text, (void *));
>   again = false;
>   for (i = 0; i < JUMP_NB && keys[i]; i++)
>   if (dres == keys[i]) {

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html