Re: [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO

[Randy Dunlap]

On 10/27/14 06:13, Tomi Valkeinen wrote:
> On 27/10/14 13:59, Jani Nikula wrote:
> 
>>> While doing 'depends on' instead of 'select' is an "easy" fix for this,
>>> I do dislike it quite a bit. It's a major pain to go around the kernel
>>> config, trying to find all the dependencies that a particular driver
>>> wants. If I need fb-foobar, I should just be able to enable it, instead
>>> of first searching and selecting its minor dependencies individually.
>>
>> Agreed, but I don't think that's specific to this patch.
> 
> Well, no, the generic problem is not specific to this patch, but we can
> avoid the issue with proper use of 'select' (at least in some cases),
> which is specific to this patch.
> 
>>> So, not a NACK, but a "isn't there an another way to fix this?".
>>
>> I think the real answer would be to fix kconfig to also show menu items
>> whose dependencies are not met, and then recursively enabling the
>> dependencies when the item is enabled. Beyond my scope.
>>
>>> Looking at backlight... BACKLIGHT_LCD_SUPPORT seems to be a "meta"
>>> option, it only enables a Kconfig submenu.
>>>
>>> So I think we could just remove the whole BACKLIGHT_LCD_SUPPORT option.
>>> But if we do that, all the items in drivers/video/backlight/Kconfig with
>>> default 'y' or 'm' would get enabled by default, so I think we should
>>> remove the 'default's from that file. That makes sense in any case, as I
>>> don't see why "HP Jornada 700 series LCD Driver" should be "default y".
>>>
>>> BACKLIGHT_CLASS_DEVICE doesn't depend on anything except
>>> BACKLIGHT_LCD_SUPPORT, so after removing BACKLIGHT_LCD_SUPPORT it should
>>> be safe to 'select' BACKLIGHT_CLASS_DEVICE.
>>>
>>> BACKLIGHT_CLASS_DEVICE could be made a hidden option, and the drivers in
>>> drivers/video/backlight/Kconfig which are under BACKLIGHT_CLASS_DEVICE
>>> could be made to select BACKLIGHT_CLASS_DEVICE instead.
>>
>> I think it should be possible to choose between y and m when it's
> 
> If I'm not mistaken, if CONFIG_FOO is 'm', and it 'select's CONFIG_BAR,
> and CONFIG_BAR is tristate, then CONFIG_BAR will be set to 'm'.
> 
>> selected, and it should be possible to enable it when it's not selected
>> by any drivers. I'm not sure a hidden option is good for that.
> 
> Why would you want to enable it if no one uses it? Does
> BACKLIGHT_CLASS_DEVICE enable something even if no driver uses it?
> 
>>> That doesn't exactly fix anything, but I think it makes sense as
>>> BACKLIGHT_CLASS_DEVICE is something that's selected from all around the
>>> kernel, so it should be a selectable "library" instead of a Kconfig menu
>>> option.
>>
>> At least for drm/i915 BACKLIGHT_CLASS_DEVICE is "an option". We use it
>> if it's enabled, but we are just fine if it's not. I've learned the way
>> to express that is
>>
>>  depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
>>
>> but I don't think there's a way to express that in terms of select, is
>> there? The dependency above guarantees there's no DRM_I915=y and
>> BACKLIGHT_CLASS_DEVICE=m combo which would fail. And this, btw, is where
>> this whole patch got started, as select didn't handle that properly.
> 
> If backlight support is considered an option for drm/i915, then I think
> there should be a Kconfig option for i915 to enable backlight support,
> which in turn selects BACKLIGHT_CLASS_DEVICE. And that select will force
> BACKLIGHT_CLASS_DEVICE to be built-in if drm/i915 is built-in.
> 
> Oh, but it doesn't work optimally with modules. The new option needed
> for that would be boolean, so BACKLIGHT_CLASS_DEVICE would always be
> either y or n. Sigh...
> 
>>> I didn't look at the ACPI_VIDEO side, so no idea how messy that is.
>>
>> Basically it's another dependency on BACKLIGHT_CLASS_DEVICE. I can only
>> imagine trying to solve this problem with select is going to end up in
>> recursive dependencies that spread out and need changing about as wide
>> as this patch.
> 
> If ACPI_VIDEO uses select to enable BACKLIGHT_CLASS_DEVICE, then, I
> think, selecting ACPI_VIDEO will also select BACKLIGHT_CLASS_DEVICE. So
> I don't right away see any recursive dependencies. Or what did you have
> in mind?
> 
>> In the end, I agree with the problem you have with this patch, but yet I
>> think it's the right thing to do in terms of expressing the
>> dependencies.
> 
> Well, dri/i915 doesn't exactly depend on backlight, if I understood you
> correctly. Instead, backlight is an option for dri/i915, and you kind of
> hack it to be implemented with that 'depends on BACKLIGHT_CLASS_DEVICE
> || BACKLIGHT_CLASS_DEVICE=n'.
> 
> I guess it's debatable whether drivers should automatically use features
> in the kernel if they happen to be enabled in the Kconfig, or should
> they be individually enabled for that driver. I personally like the
> latter option, as it allows more precise control, but it probably also
> depends on the feature in question.
> 
> I also think the 'depends on BACKLIGHT_CLASS_DEVICE ||
> BACKLIGHT_CLASS_DEV

Re: [PATCH RFC] Update kernel math-emu code from current glibc soft-fp

[Randy Dunlap]

On 02/06/15 09:25, Joseph Myers wrote:
> At this point this patch is an RFC rather than yet being ready for
> inclusion, because I've only tested it for powerpc (both e500 and
> emulation of classic hard float); it's quite likely there are bugs in
> the changes for other architectures, quite possibly breaking the
> build.  I've also posted it to libc-alpha
>  with a
> call for testing and notes on what testing might be appropriate.

Is there a test suite?


and a diffstat is good to see:

 arch/alpha/include/asm/sfp-machine.h|3 
 arch/alpha/math-emu/math.c  |  131 -
 arch/powerpc/include/asm/sfp-machine.h  |   39 
 arch/powerpc/math-emu/fadd.c|6 
 arch/powerpc/math-emu/fadds.c   |6 
 arch/powerpc/math-emu/fcmpo.c   |2 
 arch/powerpc/math-emu/fcmpu.c   |2 
 arch/powerpc/math-emu/fctiw.c   |2 
 arch/powerpc/math-emu/fctiwz.c  |2 
 arch/powerpc/math-emu/fmadd.c   |8 
 arch/powerpc/math-emu/fmadds.c  |8 
 arch/powerpc/math-emu/fmsub.c   |8 
 arch/powerpc/math-emu/fmsubs.c  |8 
 arch/powerpc/math-emu/fnmadd.c  |8 
 arch/powerpc/math-emu/fnmadds.c |8 
 arch/powerpc/math-emu/fnmsub.c  |8 
 arch/powerpc/math-emu/fnmsubs.c |8 
 arch/powerpc/math-emu/fsub.c|6 
 arch/powerpc/math-emu/fsubs.c   |6 
 arch/powerpc/math-emu/lfs.c |   11 
 arch/powerpc/math-emu/math_efp.c|  254 +-
 arch/powerpc/math-emu/stfs.c|6 
 arch/s390/include/asm/sfp-machine.h |   10 
 arch/s390/math-emu/math.c   |  278 +--
 arch/sh/include/asm/sfp-machine.h   |   10 
 arch/sh/math-emu/math.c |   51 
 arch/sparc/include/asm/sfp-machine_32.h |3 
 arch/sparc/include/asm/sfp-machine_64.h |3 
 arch/sparc/math-emu/math_32.c   |  144 -
 arch/sparc/math-emu/math_64.c   |  140 -
 include/math-emu/double.h   |  391 ++--
 include/math-emu/op-1.h |  546 +++---
 include/math-emu/op-2.h | 1127 ++--
 include/math-emu/op-4.h | 1449 ---
 include/math-emu/op-8.h |  205 +-
 include/math-emu/op-common.h| 2902 ++--
 include/math-emu/quad.h |  428 +++-
 include/math-emu/single.h   |  225 +-
 include/math-emu/soft-fp.h  |  342 ++-
 39 files changed, 5495 insertions(+), 3299 deletions(-)




-- 
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFC 2/5] x86/speculation: Add support for 'cpu_spec_mitigations=' cmdline options

[Randy Dunlap]

On 4/5/19 6:57 AM, Borislav Petkov wrote:
> On Thu, Apr 04, 2019 at 11:44:12AM -0500, Josh Poimboeuf wrote:
>> Configure x86 runtime CPU speculation bug mitigations in accordance with
>> the 'cpu_spec_mitigations=' cmdline options.  This affects Meltdown,
>> Spectre v2, Speculative Store Bypass, and L1TF.
>>
>> The default behavior is unchanged.
>>
>> Signed-off-by: Josh Poimboeuf 
>> ---
>>  .../admin-guide/kernel-parameters.txt | 15 +
>>  arch/x86/include/asm/processor.h  |  1 +
>>  arch/x86/kernel/cpu/bugs.c| 32 ---
>>  arch/x86/kvm/vmx/vmx.c|  2 ++
>>  arch/x86/mm/pti.c |  4 ++-
>>  5 files changed, 49 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index ac42e510bd6e..29dc03971630 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -2552,6 +2552,11 @@
>>  
>>  off
>>  Disable all speculative CPU mitigations.
>> +Equivalent to: nopti [x86]
>> +   nospectre_v2 [x86]
>> +   spectre_v2_user=off [x86]
>> +   spec_store_bypass_disable=off 
>> [x86]
>> +   l1tf=off [x86]
>>  
>>  auto (default)
>>  Mitigate all speculative CPU vulnerabilities,
>> @@ -2560,12 +2565,22 @@
>>  surprised by SMT getting disabled across kernel
>>  upgrades, or who have other ways of avoiding
>>  SMT-based attacks.
>> +Equivalent to: pti=auto [x86]
>> +   spectre_v2=auto [x86]
>> +   spectre_v2_user=auto [x86]
>> +   spec_store_bypass_disable=auto 
>> [x86]
>> +   l1tf=flush [x86]
>>  
>>  auto,nosmt
>>  Mitigate all speculative CPU vulnerabilities,
>>  disabling SMT if needed.  This is for users who
>>  always want to be fully mitigated, even if it
>>  means losing SMT.
>> +Equivalent to: pti=auto [x86]
>> +   spectre_v2=auto [x86]
>> +   spectre_v2_user=auto [x86]
>> +   spec_store_bypass_disable=auto 
>> [x86]
>> +   l1tf=flush,nosmt [x86]
>>  
>>  mminit_loglevel=
>>  [KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
> 
> Yap, those sets look ok.

nit:  s/x86/X86/g
according to Documentation/admin-guide/kernel-parameters.rst


-- 
~Randy

Re: [PATCH v2 5/5] arm64/speculation: Support 'mitigations=' cmdline option

[Randy Dunlap]

On 4/12/19 1:39 PM, Josh Poimboeuf wrote:
> Configure arm64 runtime CPU speculation bug mitigations in accordance
> with the 'mitigations=' cmdline option.  This affects Meltdown, Spectre
> v2, and Speculative Store Bypass.
> 
> The default behavior is unchanged.
> 
> Signed-off-by: Josh Poimboeuf 
> ---
> NOTE: This is based on top of Jeremy Linton's patches:
>   https://lkml.kernel.org/r/20190410231237.52506-1-jeremy.lin...@arm.com
> 
>  Documentation/admin-guide/kernel-parameters.txt | 8 +---
>  arch/arm64/kernel/cpu_errata.c  | 6 +-
>  arch/arm64/kernel/cpufeature.c  | 8 +++-
>  3 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index e84a01d90e92..79bfc755defe 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2545,8 +2545,8 @@
>   http://repo.or.cz/w/linux-2.6/mini2440.git
>  
>   mitigations=
> - [X86,PPC,S390] Control optional mitigations for CPU
> - vulnerabilities.  This is a set of curated,
> + [X86,PPC,S390,ARM64] Control optional mitigations for
> + CPU vulnerabilities.  This is a set of curated,
>   arch-independent options, each of which is an
>   aggregation of existing arch-specific options.
>  
> @@ -2555,11 +2555,13 @@
>   improves system performance, but it may also
>   expose users to several CPU vulnerabilities.
>   Equivalent to: nopti [X86,PPC]
> +kpti=0 [ARM64]
>  nospectre_v1 [PPC]
>  nobp=0 [S390]
> -nospectre_v2 [X86,PPC,S390]
> +nospectre_v2 [X86,PPC,S390,ARM64]
>  spectre_v2_user=off [X86]
>  spec_store_bypass_disable=off 
> [X86,PPC]
> +ssbd=force-off [ARM64]
>  l1tf=off [X86]
>  
>   auto (default)

Hi,
Do we need to add "ARM64" to Documentation/admin-guide/kernel-parameters.rst?


-- 
~Randy

Re: [PATCH] Documentation: Add ARM64 to kernel-parameters.rst

[Randy Dunlap]

On 4/12/19 8:56 PM, Josh Poimboeuf wrote:
> Add ARM64 to the legend of architectures.  It's already used in several
> places in kernel-parameters.txt.
> 
> Suggested-by: Randy Dunlap 
> Signed-off-by: Josh Poimboeuf 
> ---
>  Documentation/admin-guide/kernel-parameters.rst | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.rst 
> b/Documentation/admin-guide/kernel-parameters.rst
> index b8d0bc07ed0a..0124980dca2d 100644
> --- a/Documentation/admin-guide/kernel-parameters.rst
> +++ b/Documentation/admin-guide/kernel-parameters.rst
> @@ -88,6 +88,7 @@ parameter is applicable::
>   APICAPIC support is enabled.
>   APM Advanced Power Management support is enabled.
>   ARM ARM architecture is enabled.
> + ARM64   ARM64 architecture is enabled.
>   AX25Appropriate AX.25 support is enabled.
>   CLK Common clock infrastructure is enabled.
>   CMA Contiguous Memory Area support is enabled.
> 


Thanks.

-- 
~Randy

Re: [PATCH 4/4] hugetlbfs: clean up command line processing

[Randy Dunlap]

Hi Mike,

On 3/18/20 3:06 PM, Mike Kravetz wrote:
> With all hugetlb page processing done in a single file clean up code.
> - Make code match desired semantics
>   - Update documentation with semantics
> - Make all warnings and errors messages start with 'HugeTLB:'.
> - Consistently name command line parsing routines.
> - Add comments to code
>   - Describe some of the subtle interactions
>   - Describe semantics of command line arguments
> 
> Signed-off-by: Mike Kravetz 
> ---
>  Documentation/admin-guide/mm/hugetlbpage.rst | 26 +++
>  mm/hugetlb.c | 78 +++-
>  2 files changed, 87 insertions(+), 17 deletions(-)


> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index cc85b4f156ca..2b9bf01db2b6 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c

> @@ -3214,8 +3238,15 @@ static int __init hugetlb_nrpages_setup(char *s)
>  
>   return 1;
>  }
> -__setup("hugepages=", hugetlb_nrpages_setup);
> +__setup("hugepages=", hugepages_setup);
>  
> +/*
> + * hugepagesz command line processing
> + * A specific huge page size can only be specified once with hugepagesz.
> + * hugepagesz is followed by hugepages on the commnad line.  The global

typo:command

> + * variable 'parsed_valid_hugepagesz' is used to determine if prior
> + * hugepagesz argument was valid.
> + */
>  static int __init hugepagesz_setup(char *s)
>  {
>   unsigned long long size;


Does any of this need to be updated?  (from 
Documentation/admin-guide/kernel-parameters.txt)

hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
On x86-64 and powerpc, this option can be specified
multiple times interleaved with hugepages= to reserve
huge pages of different sizes. Valid pages sizes on
x86-64 are 2M (when the CPU supports "pse") and 1G
(when the CPU supports the "pdpe1gb" cpuinfo flag).


-- 
~Randy

[PATCH v2] Documentation/locking/locktypes: minor copy editor fixes

[Randy Dunlap]

From: Randy Dunlap 

Minor editorial fixes:
- add some hyphens in multi-word adjectives
- add some periods for consistency
- add "'" for possessive CPU's
- capitalize IRQ when it's an acronym and not part of a function name

Signed-off-by: Randy Dunlap 
Cc: Paul McKenney 
Cc: Thomas Gleixner 
Cc: Sebastian Siewior 
Cc: Joel Fernandes 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
---
 Documentation/locking/locktypes.rst |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

--- linux-next-20200325.orig/Documentation/locking/locktypes.rst
+++ linux-next-20200325/Documentation/locking/locktypes.rst
@@ -84,7 +84,7 @@ rtmutex
 
 RT-mutexes are mutexes with support for priority inheritance (PI).
 
-PI has limitations on non PREEMPT_RT enabled kernels due to preemption and
+PI has limitations on non-PREEMPT_RT-enabled kernels due to preemption and
 interrupt disabled sections.
 
 PI clearly cannot preempt preemption-disabled or interrupt-disabled
@@ -150,7 +150,7 @@ kernel configuration including PREEMPT_R
 
 raw_spinlock_t is a strict spinning lock implementation in all kernels,
 including PREEMPT_RT kernels.  Use raw_spinlock_t only in real critical
-core code, low level interrupt handling and places where disabling
+core code, low-level interrupt handling and places where disabling
 preemption or interrupts is required, for example, to safely access
 hardware state.  raw_spinlock_t can sometimes also be used when the
 critical section is tiny, thus avoiding RT-mutex overhead.
@@ -160,20 +160,20 @@ spinlock_t
 
 The semantics of spinlock_t change with the state of PREEMPT_RT.
 
-On a non PREEMPT_RT enabled kernel spinlock_t is mapped to raw_spinlock_t
+On a non-PREEMPT_RT-enabled kernel spinlock_t is mapped to raw_spinlock_t
 and has exactly the same semantics.
 
 spinlock_t and PREEMPT_RT
 -
 
-On a PREEMPT_RT enabled kernel spinlock_t is mapped to a separate
+On a PREEMPT_RT-enabled kernel spinlock_t is mapped to a separate
 implementation based on rt_mutex which changes the semantics:
 
- - Preemption is not disabled
+ - Preemption is not disabled.
 
  - The hard interrupt related suffixes for spin_lock / spin_unlock
-   operations (_irq, _irqsave / _irqrestore) do not affect the CPUs
-   interrupt disabled state
+   operations (_irq, _irqsave / _irqrestore) do not affect the CPU's
+   interrupt disabled state.
 
  - The soft interrupt related suffix (_bh()) still disables softirq
handlers.
@@ -279,7 +279,7 @@ fully preemptible context.  Instead, use
 spin_lock_irqsave() and their unlock counterparts.  In cases where the
 interrupt disabling and locking must remain separate, PREEMPT_RT offers a
 local_lock mechanism.  Acquiring the local_lock pins the task to a CPU,
-allowing things like per-CPU irq-disabled locks to be acquired.  However,
+allowing things like per-CPU IRQ-disabled locks to be acquired.  However,
 this approach should be used only where absolutely necessary.
 
 

Re: [PATCH v2 4/4] hugetlbfs: clean up command line processing

[Randy Dunlap]

On 4/1/20 11:38 AM, Mike Kravetz wrote:
> With all hugetlb page processing done in a single file clean up code.
> - Make code match desired semantics
>   - Update documentation with semantics
> - Make all warnings and errors messages start with 'HugeTLB:'.
> - Consistently name command line parsing routines.
> - Check for hugepages_supported() before processing parameters.
> - Add comments to code
>   - Describe some of the subtle interactions
>   - Describe semantics of command line arguments
> 
> Signed-off-by: Mike Kravetz 
> ---

Hi Mike,
One nit, please see below:

>  .../admin-guide/kernel-parameters.txt | 35 ---
>  Documentation/admin-guide/mm/hugetlbpage.rst  | 44 +
>  mm/hugetlb.c  | 96 +++
>  3 files changed, 142 insertions(+), 33 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index 1bd5454b5e5f..de653cfe1726 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -832,12 +832,15 @@
>   See also Documentation/networking/decnet.txt.
>  
>   default_hugepagesz=
> - [same as hugepagesz=] The size of the default
> - HugeTLB page size. This is the size represented by
> - the legacy /proc/ hugepages APIs, used for SHM, and
> - default size when mounting hugetlbfs filesystems.
> - Defaults to the default architecture's huge page size
> - if not specified.
> + [HW] The size of the default HugeTLB page size. This

Drop one "size" above?

> + is the size represented by the legacy /proc/ hugepages
> + APIs.  In addition, this is the default hugetlb size
> + used for shmget(), mmap() and mounting hugetlbfs
> + filesystems.  If not specified, defaults to the
> + architecture's default huge page size.  Huge page
> + sizes are architecture dependent.  See also
> + Documentation/admin-guide/mm/hugetlbpage.rst.
> + Format: size[KMG]



-- 
~Randy

[PATCH] powerpc: indent Kconfig depends continuation line

[Randy Dunlap]

From: Randy Dunlap 

Indent a Kconfig continuation line to improve readability.

Signed-off-by: Randy Dunlap 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-54.orig/arch/powerpc/Kconfig
+++ lnx-54/arch/powerpc/Kconfig
@@ -468,7 +468,7 @@ config MPROFILE_KERNEL
 config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
depends on SMP && (PPC_PSERIES || \
-   PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE)
+   PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE)
help
  Say Y here to be able to disable and re-enable individual
  CPUs at runtime on SMP machines.

Re: [PATCH 09/28] mm: rename CONFIG_PGTABLE_MAPPING to CONFIG_ZSMALLOC_PGTABLE_MAPPING

[Randy Dunlap]

On 4/8/20 4:59 AM, Christoph Hellwig wrote:
> Rename the Kconfig variable to clarify the scope.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/arm/configs/omap2plus_defconfig | 2 +-
>  include/linux/zsmalloc.h | 2 +-
>  mm/Kconfig   | 2 +-
>  mm/zsmalloc.c| 8 
>  4 files changed, 7 insertions(+), 7 deletions(-)
> 

Looks good. Thanks.

Acked-by: Randy Dunlap 


-- 
~Randy

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

[Randy Dunlap]

Hi,

On 4/8/20 4:59 AM, Christoph Hellwig wrote:
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 36949a9425b8..614cc786b519 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -702,7 +702,7 @@ config ZSMALLOC
>  
>  config ZSMALLOC_PGTABLE_MAPPING
>   bool "Use page table mapping to access object in zsmalloc"
> - depends on ZSMALLOC
> + depends on ZSMALLOC=y

It's a bool so this shouldn't matter... not needed.

>   help
> By default, zsmalloc uses a copy-based object mapping method to
> access allocations that span two pages. However, if a particular


-- 
~Randy

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

[Randy Dunlap]

On 4/8/20 8:15 AM, Matthew Wilcox wrote:
> On Wed, Apr 08, 2020 at 05:12:03PM +0200, Peter Zijlstra wrote:
>> On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote:
>>> Hi,
>>>
>>> On 4/8/20 4:59 AM, Christoph Hellwig wrote:
>>>> diff --git a/mm/Kconfig b/mm/Kconfig
>>>> index 36949a9425b8..614cc786b519 100644
>>>> --- a/mm/Kconfig
>>>> +++ b/mm/Kconfig
>>>> @@ -702,7 +702,7 @@ config ZSMALLOC
>>>>  
>>>>  config ZSMALLOC_PGTABLE_MAPPING
>>>>bool "Use page table mapping to access object in zsmalloc"
>>>> -  depends on ZSMALLOC
>>>> +  depends on ZSMALLOC=y
>>>
>>> It's a bool so this shouldn't matter... not needed.
>>
>> My mm/Kconfig has:
>>
>> config ZSMALLOC
>>  tristate "Memory allocator for compressed pages"
>>  depends on MMU
>>
>> which I think means it can be modular, no?

ack. I misread it.

> Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch
> is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become
> 'n' instead of 'y'.

sigh, I wish that I had meant that. :)

thanks.

-- 
~Randy

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

[Randy Dunlap]

On 4/8/20 8:36 AM, Christoph Hellwig wrote:
> On Wed, Apr 08, 2020 at 08:15:19AM -0700, Matthew Wilcox wrote:
>  config ZSMALLOC_PGTABLE_MAPPING
>   bool "Use page table mapping to access object in zsmalloc"
> - depends on ZSMALLOC
> + depends on ZSMALLOC=y

 It's a bool so this shouldn't matter... not needed.
>>>
>>> My mm/Kconfig has:
>>>
>>> config ZSMALLOC
>>> tristate "Memory allocator for compressed pages"
>>> depends on MMU
>>>
>>> which I think means it can be modular, no?
>>
>> Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch
>> is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become
>> 'n' instead of 'y'.
> 
> In Linus' tree you can select PGTABLE_MAPPING=y with ZSMALLOC=m,
> and that fits my understanding of the kbuild language.  With this
> patch I can't anymore.
> 

Makes sense. thanks.

-- 
~Randy

Re: [PATCH] drivers: uio: new driver uio_fsl_85xx_cache_sram

[Randy Dunlap]

On 4/17/20 10:21 AM, Wang Wenhu wrote:
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index 202ee81cfc2b..f6e6ec0089c0 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -105,6 +105,14 @@ config UIO_NETX
> To compile this driver as a module, choose M here; the module
> will be called uio_netx.
>  
> +config UIO_FSL_85XX_CACHE_SRAM
> + tristate "Freescale MPC85xx Cache-Sram driver"
> + depends on FSL_SOC_BOOKE && PPC32 && !FSL_85XX_CACHE_SRAM
> + help
> +   Generic driver for accessing the Cache-Sram form user level. This

  from

and SRAM would be better than Sram IMO. (2 places)

> +   is extremely helpful for some user-space applications that require
> +   high performance memory accesses.
> +
>  config UIO_FSL_ELBC_GPCM
>   tristate "eLBC/GPCM driver"
>   depends on FSL_LBC

thanks.
-- 
~Randy

Re: [PATCH v2 2/5] stats_fs API: create, add and remove stats_fs sources and values

[Randy Dunlap]

On 5/4/20 4:03 AM, Emanuele Giuseppe Esposito wrote:
> diff --git a/fs/Kconfig b/fs/Kconfig
> index f08fbbfafd9a..1b0de0f19e96 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -328,4 +328,10 @@ source "fs/unicode/Kconfig"
>  config IO_WQ
>   bool
>  
> +config STATS_FS
> + bool "Statistics Filesystem"
> + help
> +   stats_fs is a virtual file system that provides counters and
> +   other statistics about the running kernel.
> +
>  endmenu

Hi,

This kconfig entry should be under (inside) "Pseudo filesystems",
i.e., between 'menu "Pseudo filesystems"' and its corresponding
"endmenu".

Thanks.
-- 
~Randy

Re: [RFC PATCH 11/11] powerpc/svm: Increase SWIOTLB buffer size

[Randy Dunlap]

On 08/24/2018 09:25 AM, Thiago Jung Bauermann wrote:
> From: Anshuman Khandual 
> 
> SWIOTLB buffer default size (64MB) is not enough for large sequential write
> operations which eventually leads to kernel crash like here.
> 
> virtio-pci :00:05.0: swiotlb buffer is full (sz: 327680 bytes)
> virtio-pci :00:05.0: DMA: Out of SW-IOMMU space for 327680 bytes
> Kernel panic - not syncing: DMA: Random memory could be DMA read
> CPU: 12 PID: 3985 Comm: mkfs.ext4 Not tainted 4.18.0-rc4+ #285
> Call Trace:
> [c007d2a27020] [c0cfdffc] dump_stack+0xb0/0xf4 (unreliable)
> [c007d2a27060] [c0112a98] panic+0x140/0x328
> [c007d2a270f0] [c01b4f88] swiotlb_full+0x108/0x130
> [c007d2a27180] [c01b5f6c] swiotlb_map_page+0x25c/0x2c0
> [c007d2a271e0] [c07bfaf8] vring_map_one_sg.isra.0+0x58/0x70
> [c007d2a27200] [c07c08dc] virtqueue_add_sgs+0x1bc/0x690
> [c007d2a272f0] [d42a1280] virtio_queue_rq+0x358/0x4a0 [virtio_blk]
> [c007d2a273d0] [c06b5d68] blk_mq_dispatch_rq_list+0x1f8/0x6d0
> ..
> 
> Increase the SWIOTLB size to 1GB on Ultravisor based secure guests.
> 
> Signed-off-by: Anshuman Khandual 
> Signed-off-by: Thiago Jung Bauermann 
> ---
>  arch/powerpc/Kconfig | 5 +
>  kernel/dma/swiotlb.c | 5 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 1466d1234723..fee7194ce9e4 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -457,6 +457,11 @@ config PPC_SVM
>  
>If unsure, say "N".
>  
> +config SWIOTLB_DEFAULT_SIZE
> +   int "Size of Software I/O TLB buffer (in MiB)"
> +   default "1024"

I would add a "range" to limit (restrict) how small or large that can be.  E.g.:

range 16 102400

or even smaller for the maximum value...

> +   depends on PPC_SVM
> +
>  config PPC_TRANSACTIONAL_MEM
> bool "Transactional Memory support for POWERPC"
> depends on PPC_BOOK3S_64
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 04b68d9dffac..32dc67422d8a 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -146,8 +146,13 @@ void swiotlb_set_max_segment(unsigned int val)
>   max_segment = rounddown(val, PAGE_SIZE);
>  }
>  
> +#ifdef CONFIG_SWIOTLB_DEFAULT_SIZE
> +#define IO_TLB_DEFAULT_SIZE ((unsigned long) CONFIG_SWIOTLB_DEFAULT_SIZE << 
> 20)
> +#else
>  /* default to 64MB */
>  #define IO_TLB_DEFAULT_SIZE (64UL<<20)
> +#endif
> +
>  unsigned long swiotlb_size_or_default(void)
>  {
>   unsigned long size;
> 


-- 
~Randy

Build regressions/improvements in v4.20-rc1 (sound/pci/hda/patch_ca0132.c)

[Randy Dunlap]

On 11/5/18 2:12 PM, Geert Uytterhoeven wrote:
> On Mon, Nov 5, 2018 at 11:07 PM Geert Uytterhoeven  
> wrote:
>> Below is the list of build error/warning regressions/improvements in
>> v4.20-rc1[1] compared to v4.19[2].
>>
>> Summarized:
>>   - build errors: +3/-0
>>   - build warnings: +449/-2712
>>
>> Happy fixing! ;-)
>>
>> Thanks to the linux-next team for providing the build service.
>>
>> [1] 
>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/651022382c7f8da46cb4872a545ee1da6d097d2a/
>>  (all 240 configs)
>> [2] 
>> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d/
>>  (all 240 configs)
>>
>>
>> *** ERRORS ***
>>
>>   + /kisskb/src/sound/pci/hda/patch_ca0132.c: error: implicit declaration of 
>> function 'pci_iomap' [-Werror=implicit-function-declaration]:  => 8799:3
> 
> sh4-all{mod,yes}config
> 
> Looks like d9b84a15892c0233 ("ALSA: hda: Fix implicit definition of
> pci_iomap() on SH")
> is not sufficient?

Different problem.  This is about "select":

config SND_SOC_ALL_CODECS
tristate "Build all ASoC CODEC drivers"

That enables (sets):
select SND_SOC_HDAC_HDA
which selects SND_HDA even though CONFIG_PCI is not enabled.

After SND_HDA is selected (above), the Kconfig symbols in
sound/pci/hda/Kconfig are available for enabling, so
SND_HDA_CODEC_CA0132 is enabled but will not build.


One simple solution (but possibly too naive) is:

---
 sound/soc/codecs/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-420-rc1.orig/sound/soc/codecs/Kconfig
+++ lnx-420-rc1/sound/soc/codecs/Kconfig
@@ -82,7 +82,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_ES7241
select SND_SOC_GTM601
select SND_SOC_HDAC_HDMI
-   select SND_SOC_HDAC_HDA
+   select SND_SOC_HDAC_HDA if PCI
select SND_SOC_ICS43432
select SND_SOC_INNO_RK3036
select SND_SOC_ISABELLE if I2C




-- 
~Randy

Re: [PATCH v1 9/9] mm: better document PG_reserved

[Randy Dunlap]

On 12/14/18 3:10 AM, David Hildenbrand wrote:
> The usage of PG_reserved and how PG_reserved pages are to be treated is
> buried deep down in different parts of the kernel. Let's shine some light
> onto these details by documenting current users and expected
> behavior.
> 
> Especially, clarify on the "Some of them might not even exist" case.
> These are physical memory gaps that will never be dumped as they
> are not marked as IORESOURCE_SYSRAM. PG_reserved does in general not
> hinder anybody from dumping or swapping. In some cases, these pages
> will not be stored in the hibernation image.

Hi,
Thanks for the doc update.
Comments below.

> Cc: Andrew Morton 
> Cc: Stephen Rothwell 
> Cc: Pavel Tatashin 
> Cc: Michal Hocko 
> Cc: Alexander Duyck 
> Cc: Matthew Wilcox 
> Cc: Anthony Yznaga 
> Cc: Miles Chen 
> Cc: yi.z.zh...@linux.intel.com
> Cc: Dan Williams 
> Signed-off-by: David Hildenbrand 
> ---
>  include/linux/page-flags.h | 33 +++--
>  1 file changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 808b4183e30d..9de2e941cbd5 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -17,8 +17,37 @@
>  /*
>   * Various page->flags bits:
>   *
> - * PG_reserved is set for special pages, which can never be swapped out. Some
> - * of them might not even exist...
> + * PG_reserved is set for special pages. The "struct page" of such a page
> + * should in general not be touched (e.g. set dirty) except by their owner.

   by its owner.

> + * Pages marked as PG_reserved include:
> + * - Pages part of the kernel image (including vDSO) and similar (e.g. BIOS,
> + *   initrd, HW tables)
> + * - Pages reserved or allocated early during boot (before the page allocator
> + *   was initialized). This includes (depending on the architecture) the
> + *   initial vmmap, initial page tables, crashkernel, elfcorehdr, and much

VM map,

> + *   much more. Once (if ever) freed, PG_reserved is cleared and they will
> + *   be given to the page allocator.
> + * - Pages falling into physical memory gaps - not IORESOURCE_SYSRAM. Trying
> + *   to read/write these pages might end badly. Don't touch!
> + * - The zero page(s)
> + * - Pages not added to the page allocator when onlining a section because
> + *   they were excluded via the online_page_callback() or because they are
> + *   PG_hwpoison.
> + * - Pages allocated in the context of kexec/kdump (loaded kernel image,
> + *   control pages, vmcoreinfo)
> + * - MMIO/DMA pages. Some architectures don't allow to ioremap pages that are
> + *   not marked PG_reserved (as they might be in use by somebody else who 
> does
> + *   not respect the caching strategy).
> + * - Pages part of an offline section (struct pages of offline sections 
> should
> + *   not be trusted as they will be initialized when first onlined).
> + * - MCA pages on ia64
> + * - Pages holding CPU notes for POWER Firmware Assisted Dump
> + * - Device memory (e.g. PMEM, DAX, HMM)
> + * Some PG_reserved pages will be excluded from the hibernation image.
> + * PG_reserved does in general not hinder anybody from dumping or swapping
> + * and is no longer required for remap_pfn_range(). ioremap might require it.
> + * Consequently, PG_reserved for a page mapped into user space can indicate
> + * the zero page, the vDSO, MMIO pages or device memory.
>   *
>   * The PG_private bitflag is set on pagecache pages if they contain 
> filesystem
>   * specific data (which is normally at page->private). It can be used by
> 

cheers.
-- 
~Randy

Re: microblaze HAVE_MEMBLOCK_NODE_MAP dependency (was Re: [PATCH v2 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA)

[Randy Dunlap]

On 7/31/19 10:15 AM, Mike Rapoport wrote:
> On Wed, Jul 31, 2019 at 04:41:14PM +0200, Michal Hocko wrote:
>> On Wed 31-07-19 17:21:29, Mike Rapoport wrote:
>>> On Wed, Jul 31, 2019 at 03:00:37PM +0200, Michal Hocko wrote:

 I am sorry, but I still do not follow. Who is consuming that node id
 information when NUMA=n. In other words why cannot we simply do
>>>  
>>> We can, I think nobody cared to change it.
>>
>> It would be great if somebody with the actual HW could try it out.
>> I can throw a patch but I do not even have a cross compiler in my
>> toolbox.
> 
> Well, it compiles :)

Adding Michal Simek .

It's not clear that the MICROBLAZE maintainer is still supporting MICROBLAZE.

 diff --git a/arch/microblaze/mm/init.c b/arch/microblaze/mm/init.c
 index a015a951c8b7..3a47e8db8d1c 100644
 --- a/arch/microblaze/mm/init.c
 +++ b/arch/microblaze/mm/init.c
 @@ -175,14 +175,9 @@ void __init setup_memory(void)
  
start_pfn = memblock_region_memory_base_pfn(reg);
end_pfn = memblock_region_memory_end_pfn(reg);
 -  memblock_set_node(start_pfn << PAGE_SHIFT,
 -(end_pfn - start_pfn) << PAGE_SHIFT,
 -&memblock.memory, 0);
 +  memory_present(0, start_pfn << PAGE_SHIFT, end_pfn << 
 PAGE_SHIFT);
>>>
>>> memory_present() expects pfns, the shift is not needed.
>>
>> Right.
>>
>> -- 
>> Michal Hocko
>> SUSE Labs


-- 
~Randy

Re: [PATCH 1/1] docs: powerpc: Convert to RST format

[Randy Dunlap]

On 2/6/19 10:03 PM, Tobin C. Harding wrote:
> The PowerPC docs have yet to be converted to RST format.  Let's kick it
> off by doing all the files that _don't_ contain ASCII art.
> 
> - Add SPDX license identifier to each new RST file.
> 
> .. SPDX-License-Identifier: GPL-2.0
> 
> - User correct heading adornments.
> 
> - Make all lines < 72 characters in width.
> 
> - Use correct indentation for code blocks, add syntax highlighting
> 
> - Sparingly use double ticks if it makes the files easier to parse
>   both in text and on the web.
> 
> - Fix any super obvious typos (lean towards not making changes so that
>   we don't introduce errors).
> 
> Edited as text files (obviously) and formatted as HTML to verify
> rendering, no other formats verified.
> 
> Convert docs to RST format, adding license.
> 
> Signed-off-by: Tobin C. Harding 

Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 

thanks.


> ---
>  Documentation/index.rst   |   1 +
>  Documentation/powerpc/DAWR-POWER9.rst |  60 
>  Documentation/powerpc/DAWR-POWER9.txt |  58 ---
>  Documentation/powerpc/bootwrapper.rst | 140 
>  Documentation/powerpc/bootwrapper.txt | 141 
>  Documentation/powerpc/conf.py |  10 +
>  Documentation/powerpc/cpu_features.rst|  62 
>  Documentation/powerpc/cpu_features.txt|  56 ---
>  .../powerpc/eeh-pci-error-recovery.rst| 319 +
>  .../powerpc/eeh-pci-error-recovery.txt| 334 --
>  Documentation/powerpc/index.rst   |  21 ++
>  Documentation/powerpc/isa-versions.rst| 234 
>  Documentation/powerpc/mpc52xx.rst |  52 +++
>  Documentation/powerpc/mpc52xx.txt |  39 --
>  Documentation/powerpc/pmu-ebb.rst | 148 
>  Documentation/powerpc/pmu-ebb.txt | 137 ---
>  Documentation/powerpc/ptrace.rst  | 177 ++
>  Documentation/powerpc/ptrace.txt  | 151 
>  .../{syscall64-abi.txt => syscall64-abi.rst}  |  80 +++--
>  .../powerpc/transactional_memory.rst  | 259 ++
>  .../powerpc/transactional_memory.txt  | 244 -
>  21 files changed, 1460 insertions(+), 1263 deletions(-)
>  create mode 100644 Documentation/powerpc/DAWR-POWER9.rst
>  delete mode 100644 Documentation/powerpc/DAWR-POWER9.txt
>  create mode 100644 Documentation/powerpc/bootwrapper.rst
>  delete mode 100644 Documentation/powerpc/bootwrapper.txt
>  create mode 100644 Documentation/powerpc/conf.py
>  create mode 100644 Documentation/powerpc/cpu_features.rst
>  delete mode 100644 Documentation/powerpc/cpu_features.txt
>  create mode 100644 Documentation/powerpc/eeh-pci-error-recovery.rst
>  delete mode 100644 Documentation/powerpc/eeh-pci-error-recovery.txt
>  create mode 100644 Documentation/powerpc/index.rst
>  create mode 100644 Documentation/powerpc/mpc52xx.rst
>  delete mode 100644 Documentation/powerpc/mpc52xx.txt
>  create mode 100644 Documentation/powerpc/pmu-ebb.rst
>  delete mode 100644 Documentation/powerpc/pmu-ebb.txt
>  create mode 100644 Documentation/powerpc/ptrace.rst
>  delete mode 100644 Documentation/powerpc/ptrace.txt
>  rename Documentation/powerpc/{syscall64-abi.txt => syscall64-abi.rst} (58%)
>  create mode 100644 Documentation/powerpc/transactional_memory.rst
>  delete mode 100644 Documentation/powerpc/transactional_memory.txt


-- 
~Randy

Re: [RFC PATCH 16/23] watchdog/hardlockup: Add an HPET-based hardlockup detector

[Randy Dunlap]

Hi,

On 06/12/2018 05:57 PM, Ricardo Neri wrote:
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index c40c7b7..6e79833 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -828,6 +828,16 @@ config HARDLOCKUP_DETECTOR_PERF
>   bool
>   select SOFTLOCKUP_DETECTOR
>  
> +config HARDLOCKUP_DETECTOR_HPET
> + bool "Use HPET Timer for Hard Lockup Detection"
> + select SOFTLOCKUP_DETECTOR
> + select HARDLOCKUP_DETECTOR
> + depends on HPET_TIMER && HPET
> + help
> +   Say y to enable a hardlockup detector that is driven by an 
> High-Precision
> +   Event Timer. In addition to selecting this option, the command-line
> +   parameter nmi_watchdog option. See 
> Documentation/admin-guide/kernel-parameters.rst

The "In addition ..." thing is a broken (incomplete) sentence.

> +
>  #
>  # Enables a timestamp based low pass filter to compensate for perf based
>  # hard lockup detection which runs too fast due to turbo modes.


-- 
~Randy

Re: [RFC PATCH 22/23] watchdog/hardlockup/hpet: Only enable the HPET watchdog via a boot parameter

[Randy Dunlap]

On 06/12/2018 05:57 PM, Ricardo Neri wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index f2040d4..a8833c7 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2577,7 +2577,7 @@
>   Format: [state][,regs][,debounce][,die]
>  
>   nmi_watchdog=   [KNL,BUGS=X86] Debugging features for SMP kernels
> - Format: [panic,][nopanic,][num]
> + Format: [panic,][nopanic,][num,][hpet]
>   Valid num: 0 or 1
>   0 - turn hardlockup detector in nmi_watchdog off
>   1 - turn hardlockup detector in nmi_watchdog on

This says that I can use "nmi_watchdog=hpet" without using 0 or 1.
Is that correct?

> @@ -2587,6 +2587,9 @@
>   please see 'nowatchdog'.
>   This is useful when you use a panic=... timeout and
>   need the box quickly up again.
> + When hpet is specified, the NMI watchdog will be driven
> + by an HPET timer, if available in the system. Otherwise,
> + the perf-based implementation will be used.
>  
>   These settings can be accessed at runtime via
>   the nmi_watchdog and hardlockup_panic sysctls.


thanks,
-- 
~Randy

Re: [RFC PATCH 22/23] watchdog/hardlockup/hpet: Only enable the HPET watchdog via a boot parameter

[Randy Dunlap]

On 06/13/2018 05:58 PM, Ricardo Neri wrote:
> On Tue, Jun 12, 2018 at 10:26:57PM -0700, Randy Dunlap wrote:
>> On 06/12/2018 05:57 PM, Ricardo Neri wrote:
>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
>>> b/Documentation/admin-guide/kernel-parameters.txt
>>> index f2040d4..a8833c7 100644
>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>> @@ -2577,7 +2577,7 @@
>>> Format: [state][,regs][,debounce][,die]
>>>  
>>> nmi_watchdog=   [KNL,BUGS=X86] Debugging features for SMP kernels
>>> -   Format: [panic,][nopanic,][num]
>>> +   Format: [panic,][nopanic,][num,][hpet]
>>> Valid num: 0 or 1
>>> 0 - turn hardlockup detector in nmi_watchdog off
>>> 1 - turn hardlockup detector in nmi_watchdog on
>>
>> This says that I can use "nmi_watchdog=hpet" without using 0 or 1.
>> Is that correct?
> 
> Yes, this what I meant. In my view, if you set nmi_watchdog=hpet it
> implies that you want to activate the NMI watchdog. In this case, perf.
> 
> I can see how this will be ambiguous for the case of perf and arch NMI
> watchdogs.
> 
> Alternative, a new parameter could be added; such as nmi_watchdog_type. I
> didn't want to add it in this patchset as I think that a single parameter
> can handle the enablement and type of the NMI watchdog.
> 
> What do you think?

I think it's OK like it is.

thanks,
-- 
~Randy

Re: [RFC PATCH 17/23] watchdog/hardlockup/hpet: Convert the timer's interrupt to NMI

[Randy Dunlap]

On 06/19/2018 05:15 PM, Ricardo Neri wrote:
> On Sat, Jun 16, 2018 at 03:24:49PM +0200, Thomas Gleixner wrote:
>> On Fri, 15 Jun 2018, Ricardo Neri wrote:
>>> On Fri, Jun 15, 2018 at 11:19:09AM +0200, Thomas Gleixner wrote:
 On Thu, 14 Jun 2018, Ricardo Neri wrote:
> Alternatively, there could be a counter that skips reading the HPET status
> register (and the detection of hardlockups) for every X NMIs. This would
> reduce the overall frequency of HPET register reads.

 Great plan. So if the watchdog is the only NMI (because perf is off) then
 you delay the watchdog detection by that count.
>>>
>>> OK. This was a bad idea. Then, is it acceptable to have an read to an HPET
>>> register per NMI just to check in the status register if the HPET timer
>>> caused the NMI?
>>
>> The status register is useless in case of MSI. MSI is edge triggered 
>>
>> The only register which gives you proper information is the counter
>> register itself. That adds an massive overhead to each NMI, because the
>> counter register access is synchronized to the HPET clock with hardware
>> magic. Plus on larger systems, the HPET access is cross node and even
>> slower.
> 
> It starts to sound that the HPET is too slow to drive the hardlockup detector.
> 
> Would it be possible to envision a variant of this implementation? In this
> variant, the HPET only targets a single CPU. The actual hardlockup detector
> is implemented by this single CPU sending interprocessor interrupts to the
> rest of the CPUs.
> 
> In this manner only one CPU has to deal with the slowness of the HPET; the
> rest of the CPUs don't have to read or write any HPET registers. A sysfs
> entry could be added to configure which CPU will have to deal with the HPET
> timer. However, profiling could not be done accurately on such CPU.

Please forgive my simple question:

What happens when this one CPU is the one that locks up?

thnx,
-- 
~Randy

powerpc: 32BIT vs. 64BIT (PPC32 vs. PPC64)

[Randy Dunlap]

Hi,

Is there a good way (or a shortcut) to do something like:

$ make ARCH=powerpc O=PPC32 [other_options] allmodconfig
  to get a PPC32/32BIT allmodconfig

and also be able to do:

$make ARCH=powerpc O=PPC64 [other_options] allmodconfig
  to get a PPC64/64BIT allmodconfig?


Note that arch/x86, arch/sh, and arch/sparc have ways to do
some flavor(s) of this (from Documentation/kbuild/kbuild.txt;
sh and sparc based on a recent "fix" patch from me):

x86: i386 for 32 bit, x86_64 for 64 bit
sh: sh for 32 bit, sh64 for 64 bit
sparc: sparc32 for 32 bit, sparc64 for 64 bit


thanks,
-- 
~Randy

Re: powerpc: 32BIT vs. 64BIT (PPC32 vs. PPC64)

[Randy Dunlap]

On 07/06/2018 06:45 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2018-07-05 at 14:30 -0700, Randy Dunlap wrote:
>> Hi,
>>
>> Is there a good way (or a shortcut) to do something like:
>>
>> $ make ARCH=powerpc O=PPC32 [other_options] allmodconfig
>>   to get a PPC32/32BIT allmodconfig
>>
>> and also be able to do:
>>
>> $make ARCH=powerpc O=PPC64 [other_options] allmodconfig
>>   to get a PPC64/64BIT allmodconfig?
> 
> Hrm... O= is for the separate build dir, so there much be something
> else.
> 
> You mean having ARCH= aliases like ppc/ppc32 and ppc64 ?

Yes.

> That would be a matter of overriding some .config defaults I suppose, I
> don't know how this is done on other archs.
> 
> I see the aliasing trick in the Makefile but that's about it.
> 
>> Note that arch/x86, arch/sh, and arch/sparc have ways to do
>> some flavor(s) of this (from Documentation/kbuild/kbuild.txt;
>> sh and sparc based on a recent "fix" patch from me):
> 
> I fail to see what you are actually talking about here ... sorry. Do
> you have concrete examples on x86 or sparc ? From what I can tell the
> "i386" or "sparc32/sparc64" aliases just change SRCARCH in Makefile and
> 32 vs 64-bit is just a Kconfig option...

Yes, your summary is mostly correct.

I'm just looking for a way to do cross-compile builds that are close to
ppc32 allmodconfig and ppc64 allmodconfig.


>> x86: i386 for 32 bit, x86_64 for 64 bit
>> sh: sh for 32 bit, sh64 for 64 bit
>> sparc: sparc32 for 32 bit, sparc64 for 64 bit

I saw the powerpc merge-config targets after I sent this original email.
I can do my own homebrew that I prefer over those, though.


thanks,
-- 
~Randy

Re: powerpc: 32BIT vs. 64BIT (PPC32 vs. PPC64)

[Randy Dunlap]

On 07/07/2018 05:13 AM, Nicholas Piggin wrote:
> On Fri, 6 Jul 2018 21:58:29 -0700
> Randy Dunlap  wrote:
> 
>> On 07/06/2018 06:45 PM, Benjamin Herrenschmidt wrote:
>>> On Thu, 2018-07-05 at 14:30 -0700, Randy Dunlap wrote:  
>>>> Hi,
>>>>
>>>> Is there a good way (or a shortcut) to do something like:
>>>>
>>>> $ make ARCH=powerpc O=PPC32 [other_options] allmodconfig
>>>>   to get a PPC32/32BIT allmodconfig
>>>>
>>>> and also be able to do:
>>>>
>>>> $make ARCH=powerpc O=PPC64 [other_options] allmodconfig
>>>>   to get a PPC64/64BIT allmodconfig?  
>>>
>>> Hrm... O= is for the separate build dir, so there much be something
>>> else.
>>>
>>> You mean having ARCH= aliases like ppc/ppc32 and ppc64 ?  
>>
>> Yes.
>>
>>> That would be a matter of overriding some .config defaults I suppose, I
>>> don't know how this is done on other archs.
>>>
>>> I see the aliasing trick in the Makefile but that's about it.
>>>   
>>>> Note that arch/x86, arch/sh, and arch/sparc have ways to do
>>>> some flavor(s) of this (from Documentation/kbuild/kbuild.txt;
>>>> sh and sparc based on a recent "fix" patch from me):  
>>>
>>> I fail to see what you are actually talking about here ... sorry. Do
>>> you have concrete examples on x86 or sparc ? From what I can tell the
>>> "i386" or "sparc32/sparc64" aliases just change SRCARCH in Makefile and
>>> 32 vs 64-bit is just a Kconfig option...  
>>
>> Yes, your summary is mostly correct.
>>
>> I'm just looking for a way to do cross-compile builds that are close to
>> ppc32 allmodconfig and ppc64 allmodconfig.
> 
> Would there a problem with adding ARCH=ppc32 / ppc64 matching? This
> seems to work...
> 
> Thanks,
> Nick

Yes, this mostly works and is similar to a patch (my patch) on my test machine.
And they both work for allmodconfig, which is my primary build target.

And they both have one little quirk that is confusing when the build target
is defconfig:

When ARCH=ppc32, the terminal output (stdout) is: (using O=PPC32)

make[1]: Entering directory '/home/rdunlap/lnx/lnx-418-rc3/PPC32'
  GEN ./Makefile
*** Default configuration is based on 'ppc64_defconfig'   <<<<< NOTE <<<<<
#
# configuration written to .config
#
make[1]: Leaving directory '/home/rdunlap/lnx/lnx-418-rc3/PPC32'


I expect that can be fixed also.  :)

And the written .config file is indeed for 32BIT, not 64BIT.

Thanks, Nick.

> ---
>  Makefile   | 8 
>  arch/powerpc/Kconfig   | 9 +
>  arch/powerpc/platforms/Kconfig.cputype | 8 
>  3 files changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index c5ce55cbc543..f97204aed17a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -345,6 +345,14 @@ ifeq ($(ARCH),sh64)
> SRCARCH := sh
>  endif
>  
> +# Additional ARCH settings for powerpc
> +ifeq ($(ARCH),ppc32)
> +   SRCARCH := powerpc
> +endif
> +ifeq ($(ARCH),ppc64)
> +   SRCARCH := powerpc
> +endif
> +
>  KCONFIG_CONFIG   ?= .config
>  export KCONFIG_CONFIG
>  
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 9f2b75fe2c2d..3405b1b122be 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -1,4 +1,13 @@
>  # SPDX-License-Identifier: GPL-2.0
> +
> +config PPC64
> + bool "64-bit kernel" if "$(ARCH)" = "powerpc"
> + default "$(ARCH)" != "ppc32"
> + select ZLIB_DEFLATE
> + help
> +   This option selects whether a 32-bit or a 64-bit kernel
> +   will be built.
> +
>  source "arch/powerpc/platforms/Kconfig.cputype"
>  
>  config PPC32
> diff --git a/arch/powerpc/platforms/Kconfig.cputype 
> b/arch/powerpc/platforms/Kconfig.cputype
> index e6a1de521319..f6e5d6ef9782 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -1,12 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0
> -config PPC64
> - bool "64-bit kernel"
> - default n
> - select ZLIB_DEFLATE
> - help
> -   This option selects whether a 32-bit or a 64-bit kernel
> -   will be built.
> -
>  menu "Processor support"
>  choice
>   prompt "Processor Type"
> 


-- 
~Randy

Re: powerpc: 32BIT vs. 64BIT (PPC32 vs. PPC64)

[Randy Dunlap]

On 07/08/2018 04:51 AM, Michael Ellerman wrote:
> Randy Dunlap  writes:
>> Hi,
>>
>> Is there a good way (or a shortcut) to do something like:
> 
> The best I know of is:
> 
>> $ make ARCH=powerpc O=PPC32 [other_options] allmodconfig
>>   to get a PPC32/32BIT allmodconfig
> 
> $ echo CONFIG_PPC64=n > allmod.config
> $ KCONFIG_ALLCONFIG=1 make allmodconfig
> $ grep PPC32 .config
> CONFIG_PPC32=y
> 
> Which is still a bit clunky.
> 

That's close to what I already do.  And it's very script-able.

> 
> I looked at this a while back and the problem we have is that the 32-bit
> kernel is not a single thing. There are multiple 32-bit platforms which
> are mutually exclusive.
> 
> eg, from menuconfig:
> 
>  - 512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx
>  - Freescale 85xx
>  - Freescale 8xx
>  - AMCC 40x
>  - AMCC 44x, 46x or 47x
>  - Freescale e200
> 
> 
> So we could have a 32-bit allmodconfig, but we'd need to chose one of
> the above, and we'd still only be testing some of the code.
> 
> Having said that you're the 2nd person to ask about this, so we should
> clearly do something to make a 32-bit allmodconfig easier, even if it's
> not perfect.

Thanks.

-- 
~Randy

Re: CONFIG_ANDROID_BINDER_IPC=y (Re: powerpc: 32BIT vs. 64BIT (PPC32 vs. PPC64))

[Randy Dunlap]

On 07/13/2018 04:41 AM, Mathieu Malaterre wrote:
> Randy,
> 
> On Mon, Jul 9, 2018 at 2:00 PM Mathieu Malaterre  wrote:
>>
>> On Sun, Jul 8, 2018 at 1:53 PM Michael Ellerman  wrote:
>>>
>>> Randy Dunlap  writes:
>>>> Hi,
>>>>
>>>> Is there a good way (or a shortcut) to do something like:
>>>
>>> The best I know of is:
>>>
>>>> $ make ARCH=powerpc O=PPC32 [other_options] allmodconfig
>>>>   to get a PPC32/32BIT allmodconfig
>>>
>>> $ echo CONFIG_PPC64=n > allmod.config
>>> $ KCONFIG_ALLCONFIG=1 make allmodconfig
>>> $ grep PPC32 .config
>>> CONFIG_PPC32=y
>>>
>>> Which is still a bit clunky.
>>>
>>>
>>> I looked at this a while back and the problem we have is that the 32-bit
>>> kernel is not a single thing. There are multiple 32-bit platforms which
>>> are mutually exclusive.
>>>
>>> eg, from menuconfig:
>>>
>>>  - 512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx
>>>  - Freescale 85xx
>>>  - Freescale 8xx
>>>  - AMCC 40x
>>>  - AMCC 44x, 46x or 47x
>>>  - Freescale e200
>>
>> Most Linux distro seems to have drop support for ppc32. So I'd suggest
>> to pick Debian powperc default config (but I agree that I am a little
>> biased here).
> 
> I tried an allmode as suggest by Michael (above). But I get a build error:
> 
>   MODPOST vmlinux.o
> drivers/android/binder.o: In function `binder_thread_write':
> binder.c:(.text+0xc750): undefined reference to `__get_user_bad'
> binder.c:(.text+0xc76c): undefined reference to `__get_user_bad'
> binder.c:(.text+0xc790): undefined reference to `__get_user_bad'
> binder.c:(.text+0xc7d4): undefined reference to `__get_user_bad'
> binder.c:(.text+0xc7f4): undefined reference to `__get_user_bad'
> 
> 
> So for now I need to do: CONFIG_ANDROID_BINDER_IPC=n
> 
> How did you get passed this build failure ?

Hi,

I am not seeing an error on that driver build.

I am using gcc 8.1.0 from kernel.org:
https://mirrors.edge.kernel.org/pub/tools/crosstool/

and building on x86_64.


-- 
~Randy

Re: [PATCH 1/2] powerpc: Add ppc32_allmodconfig defconfig target

[Randy Dunlap]

On 07/09/2018 07:24 AM, Michael Ellerman wrote:
> Because the allmodconfig logic just sets every symbol to M or Y, it
> has the effect of always generating a 64-bit config, because
> CONFIG_PPC64 becomes Y.
> 
> So to make it easier for folks to test 32-bit code, provide a phony
> defconfig target that generates a 32-bit allmodconfig.
> 
> The 32-bit port has several mutually exclusive CPU types, we choose
> the Book3S variants as that's what the help text in Kconfig says is
> most com
> Signed-off-by: Michael Ellerman 

Hi Michael,

Sorry for the delay.  I was traveling (out in the boonies).

I'm trying to use 'make ppc32_allmodconfig'.  Cross-building on x86_64
with crosstools from kernel.org.  (gcc 8.1.0)

I'm getting build errors.  Looks like it's missing a header file or 3.
I looked into that but it's a long and twisty maze of passages.
Any ideas?


  CC  arch/powerpc/mm/dump_linuxpagetables.o
In file included from ../arch/powerpc/include/asm/book3s/pgtable.h:8,
 from ../arch/powerpc/include/asm/pgtable.h:18,
 from ../include/linux/hugetlb.h:12,
 from ../arch/powerpc/mm/dump_linuxpagetables.c:19:
../arch/powerpc/mm/dump_linuxpagetables.c: In function 'populate_markers':
../arch/powerpc/include/asm/book3s/32/pgtable.h:53:19: error: 'PKMAP_BASE' 
undeclared (first use in this function); did you mean 'AT_BASE'?
 #define KVIRT_TOP PKMAP_BASE
   ^~
../arch/powerpc/include/asm/book3s/32/pgtable.h:64:23: note: in expansion of 
macro 'KVIRT_TOP'
 #define IOREMAP_TOP ((KVIRT_TOP - CONFIG_CONSISTENT_SIZE) & PAGE_MASK)
   ^
../arch/powerpc/mm/dump_linuxpagetables.c:456:39: note: in expansion of macro 
'IOREMAP_TOP'
  address_markers[i++].start_address = IOREMAP_TOP;
   ^~~
../arch/powerpc/include/asm/book3s/32/pgtable.h:53:19: note: each undeclared 
identifier is reported only once for each function it appears in
 #define KVIRT_TOP PKMAP_BASE
   ^~
../arch/powerpc/include/asm/book3s/32/pgtable.h:64:23: note: in expansion of 
macro 'KVIRT_TOP'
 #define IOREMAP_TOP ((KVIRT_TOP - CONFIG_CONSISTENT_SIZE) & PAGE_MASK)
   ^
../arch/powerpc/mm/dump_linuxpagetables.c:456:39: note: in expansion of macro 
'IOREMAP_TOP'
  address_markers[i++].start_address = IOREMAP_TOP;
   ^~~
../arch/powerpc/mm/dump_linuxpagetables.c:464:39: error: implicit declaration 
of function 'PKMAP_ADDR'; did you mean 'PCI_IO_ADDR'? 
[-Werror=implicit-function-declaration]
  address_markers[i++].start_address = PKMAP_ADDR(LAST_PKMAP);
   ^~
   PCI_IO_ADDR
../arch/powerpc/mm/dump_linuxpagetables.c:464:50: error: 'LAST_PKMAP' 
undeclared (first use in this function); did you mean 'LIST_HEAD'?
  address_markers[i++].start_address = PKMAP_ADDR(LAST_PKMAP);
  ^~
  LIST_HEAD



Thanks.

> ---
>  arch/powerpc/Makefile | 5 +
>  arch/powerpc/configs/book3s_32.config | 2 ++
>  2 files changed, 7 insertions(+)
>  create mode 100644 arch/powerpc/configs/book3s_32.config
> 
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 2ea575cb3401..2556c2182789 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -354,6 +354,11 @@ mpc86xx_smp_defconfig:
>   $(call merge_into_defconfig,mpc86xx_basic_defconfig,\
>   86xx-smp 86xx-hw fsl-emb-nonhw)
>  
> +PHONY += ppc32_allmodconfig
> +ppc32_allmodconfig:
> + $(Q)$(MAKE) 
> KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/book3s_32.config \
> + -f $(srctree)/Makefile allmodconfig
> +
>  define archhelp
>@echo '* zImage  - Build default images selected by kernel config'
>@echo '  zImage.*- Compressed kernel image 
> (arch/$(ARCH)/boot/zImage.*)'
> diff --git a/arch/powerpc/configs/book3s_32.config 
> b/arch/powerpc/configs/book3s_32.config
> new file mode 100644
> index ..8721eb7b1294
> --- /dev/null
> +++ b/arch/powerpc/configs/book3s_32.config
> @@ -0,0 +1,2 @@
> +CONFIG_PPC64=n
> +CONFIG_PPC_BOOK3S_32=y
> 


-- 
~Randy

[PATCH] net/ethernet/freescale/fman: fix cross-build error

[Randy Dunlap]

From: Randy Dunlap 

  CC [M]  drivers/net/ethernet/freescale/fman/fman.o
In file included from ../drivers/net/ethernet/freescale/fman/fman.c:35:
../include/linux/fsl/guts.h: In function 'guts_set_dmacr':
../include/linux/fsl/guts.h:165:2: error: implicit declaration of function 
'clrsetbits_be32' [-Werror=implicit-function-declaration]
  clrsetbits_be32(&guts->dmacr, 3 << shift, device << shift);
  ^~~

Signed-off-by: Randy Dunlap 
Cc: Madalin Bucur 
Cc: net...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
---
Found while doing ppc32_allmodconfig builds.

 include/linux/fsl/guts.h |1 +
 1 file changed, 1 insertion(+)

--- lnx-418-rc4.orig/include/linux/fsl/guts.h
+++ lnx-418-rc4/include/linux/fsl/guts.h
@@ -16,6 +16,7 @@
 #define __FSL_GUTS_H__
 
 #include 
+#include 
 
 /**
  * Global Utility Registers.

[PATCH] chrp/nvram.c: add MODULE_LICENSE()

[Randy Dunlap]

From: Randy Dunlap 

Add MODULE_LICENSE() to the chrp nvram.c driver to fix the build
warning message:

WARNING: modpost: missing MODULE_LICENSE() in 
arch/powerpc/platforms/chrp/nvram.o

Signed-off-by: Randy Dunlap 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
---
Feel free to adjust the license string if needed.

 arch/powerpc/platforms/chrp/nvram.c |3 +++
 1 file changed, 3 insertions(+)

--- lnx-418-rc4.orig/arch/powerpc/platforms/chrp/nvram.c
+++ lnx-418-rc4/arch/powerpc/platforms/chrp/nvram.c
@@ -11,6 +11,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -89,3 +90,5 @@ void __init chrp_nvram_init(void)
 
return;
 }
+
+MODULE_LICENSE("GPL v2");

Re: [PATCH 1/2] powerpc: Add ppc32_allmodconfig defconfig target

[Randy Dunlap]

On 07/09/2018 07:24 AM, Michael Ellerman wrote:
> Because the allmodconfig logic just sets every symbol to M or Y, it
> has the effect of always generating a 64-bit config, because
> CONFIG_PPC64 becomes Y.
> 
> So to make it easier for folks to test 32-bit code, provide a phony
> defconfig target that generates a 32-bit allmodconfig.
> 
> The 32-bit port has several mutually exclusive CPU types, we choose
> the Book3S variants as that's what the help text in Kconfig says is
> most common.
> 
> Signed-off-by: Michael Ellerman 

Hi Michael,

ppc32_allmodconfig sets CONFIG_ISA=y (and other related symbols) and
CONFIG_PPC_CHRP=y.  But my builds are failing because they are missing
the functions isa_bus_to_virt() and isa_virt_to_bus().

Any ideas?

Thanks.

> ---
>  arch/powerpc/Makefile | 5 +
>  arch/powerpc/configs/book3s_32.config | 2 ++
>  2 files changed, 7 insertions(+)
>  create mode 100644 arch/powerpc/configs/book3s_32.config
> 
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 2ea575cb3401..2556c2182789 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -354,6 +354,11 @@ mpc86xx_smp_defconfig:
>   $(call merge_into_defconfig,mpc86xx_basic_defconfig,\
>   86xx-smp 86xx-hw fsl-emb-nonhw)
>  
> +PHONY += ppc32_allmodconfig
> +ppc32_allmodconfig:
> + $(Q)$(MAKE) 
> KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/book3s_32.config \
> + -f $(srctree)/Makefile allmodconfig
> +
>  define archhelp
>@echo '* zImage  - Build default images selected by kernel config'
>@echo '  zImage.*- Compressed kernel image 
> (arch/$(ARCH)/boot/zImage.*)'
> diff --git a/arch/powerpc/configs/book3s_32.config 
> b/arch/powerpc/configs/book3s_32.config
> new file mode 100644
> index ..8721eb7b1294
> --- /dev/null
> +++ b/arch/powerpc/configs/book3s_32.config
> @@ -0,0 +1,2 @@
> +CONFIG_PPC64=n
> +CONFIG_PPC_BOOK3S_32=y
> 


-- 
~Randy

[PATCH] powerpc/platforms/85xx: fix t1042rdb_diu.c build errors & warning

[Randy Dunlap]

From: Randy Dunlap 

Fix build errors and warnings in t1042rdb_diu.c by adding header files
and MODULE_LICENSE().

../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: warning: data definition 
has no type or storage class
 early_initcall(t1042rdb_diu_init);
../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: error: type defaults to 
'int' in declaration of 'early_initcall' [-Werror=implicit-int]
../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: warning: parameter names 
(without types) in function declaration

and
WARNING: modpost: missing MODULE_LICENSE() in 
arch/powerpc/platforms/85xx/t1042rdb_diu.o

Signed-off-by: Randy Dunlap 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Scott Wood 
Cc: Kumar Gala 
Cc: linuxppc-dev@lists.ozlabs.org
---
Found when using Michael's patch for ppc64_book3e_allmodconfig.

 arch/powerpc/platforms/85xx/t1042rdb_diu.c |4 
 1 file changed, 4 insertions(+)

--- lnx-418-rc4.orig/arch/powerpc/platforms/85xx/t1042rdb_diu.c
+++ lnx-418-rc4/arch/powerpc/platforms/85xx/t1042rdb_diu.c
@@ -9,8 +9,10 @@
  * option) any later version.
  */
 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -150,3 +152,5 @@ static int __init t1042rdb_diu_init(void
 }
 
 early_initcall(t1042rdb_diu_init);
+
+MODULE_LICENSE("GPL");

[PATCH] usb/phy: fix PPC64 build errors in phy-fsl-usb.c

[Randy Dunlap]

From: Randy Dunlap 

Fix build errors when built for PPC64:
These variables are only used on PPC32 so they don't need to be
initialized for PPC64.

../drivers/usb/phy/phy-fsl-usb.c: In function 'usb_otg_start':
../drivers/usb/phy/phy-fsl-usb.c:865:3: error: '_fsl_readl' undeclared (first 
use in this function); did you mean 'fsl_readl'?
   _fsl_readl = _fsl_readl_be;
../drivers/usb/phy/phy-fsl-usb.c:865:16: error: '_fsl_readl_be' undeclared 
(first use in this function); did you mean 'fsl_readl'?
   _fsl_readl = _fsl_readl_be;
../drivers/usb/phy/phy-fsl-usb.c:866:3: error: '_fsl_writel' undeclared (first 
use in this function); did you mean 'fsl_writel'?
   _fsl_writel = _fsl_writel_be;
../drivers/usb/phy/phy-fsl-usb.c:866:17: error: '_fsl_writel_be' undeclared 
(first use in this function); did you mean 'fsl_writel'?
   _fsl_writel = _fsl_writel_be;
../drivers/usb/phy/phy-fsl-usb.c:868:16: error: '_fsl_readl_le' undeclared 
(first use in this function); did you mean 'fsl_readl'?
   _fsl_readl = _fsl_readl_le;
../drivers/usb/phy/phy-fsl-usb.c:869:17: error: '_fsl_writel_le' undeclared 
(first use in this function); did you mean 'fsl_writel'?
   _fsl_writel = _fsl_writel_le;

and the sysfs "show" function return type should be ssize_t, not int:

../drivers/usb/phy/phy-fsl-usb.c:1042:49: error: initialization of 'ssize_t 
(*)(struct device *, struct device_attribute *, char *)' {aka 'long int 
(*)(struct device *, struct device_attribute *, char *)'} from incompatible 
pointer type 'int (*)(struct device *, struct device_attribute *, char *)' 
[-Werror=incompatible-pointer-types]
 static DEVICE_ATTR(fsl_usb2_otg_state, S_IRUGO, show_fsl_usb2_otg_state, NULL);

Signed-off-by: Randy Dunlap 
Cc: Felipe Balbi 
Cc: linux-...@vger.kernel.org
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
---
Found when using Michael's patch for ppc64_book3e_allmodconfig.

 drivers/usb/phy/phy-fsl-usb.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- lnx-418-rc4.orig/drivers/usb/phy/phy-fsl-usb.c
+++ lnx-418-rc4/drivers/usb/phy/phy-fsl-usb.c
@@ -861,6 +861,7 @@ int usb_otg_start(struct platform_device
if (pdata->init && pdata->init(pdev) != 0)
return -EINVAL;
 
+#ifdef CONFIG_PPC32
if (pdata->big_endian_mmio) {
_fsl_readl = _fsl_readl_be;
_fsl_writel = _fsl_writel_be;
@@ -868,6 +869,7 @@ int usb_otg_start(struct platform_device
_fsl_readl = _fsl_readl_le;
_fsl_writel = _fsl_writel_le;
}
+#endif
 
/* request irq */
p_otg->irq = platform_get_irq(pdev, 0);
@@ -958,7 +960,7 @@ int usb_otg_start(struct platform_device
 /*
  * state file in sysfs
  */
-static int show_fsl_usb2_otg_state(struct device *dev,
+static ssize_t show_fsl_usb2_otg_state(struct device *dev,
   struct device_attribute *attr, char *buf)
 {
struct otg_fsm *fsm = &fsl_otg_dev->fsm;

Re: [PATCH 2/2] powerpc: Add ppc64le and ppc64_book3e allmodconfig targets

[Randy Dunlap]

On 07/09/18 07:24, Michael Ellerman wrote:
> Similarly as we just did for 32-bit, add phony targets for generating
> a little endian and Book3E allmodconfig. These aren't covered by the
> regular allmodconfig, which is big endian and Book3S due to the way
> the Kconfig symbols are structured.

[adding Felipe Balbi]


Is book3e allmodconfig not seen/used very much?

Besides the patches that I have already sent, I am seeing a build problem
with ppc64_book3e_allmodconfig, where we have:

CONFIG_USB_PHY=y
CONFIG_FSL_USB2_OTG=y
but
CONFIG_USB_OTG_FSM=m

In drivers/usb/phy/Kconfig, FSL_USB2_OTG depends on USB_OTG_FSM (among
other things), but!  FSL_USB2_OTG is a bool symbol, depending on a
tristate symbol.  This often causes problems.  In this case it causes errors
with a builtin driver trying to use symbols that are built in a loadable module:

drivers/usb/phy/phy-fsl-usb.o: In function `.fsl_otg_ioctl':
phy-fsl-usb.c:(.text.fsl_otg_ioctl+0xb4): undefined reference to 
`.otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `.fsl_otg_start_srp':
phy-fsl-usb.c:(.text.fsl_otg_start_srp+0x4c): undefined reference to 
`.otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `.fsl_otg_set_host':
phy-fsl-usb.c:(.text.fsl_otg_set_host+0xd0): undefined reference to 
`.otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `.fsl_otg_start_hnp':
phy-fsl-usb.c:(.text.fsl_otg_start_hnp+0x68): undefined reference to 
`.otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `.show_fsl_usb2_otg_state':
phy-fsl-usb.c:(.text.show_fsl_usb2_otg_state+0x154): undefined reference to 
`.usb_otg_state_string'
drivers/usb/phy/phy-fsl-usb.o: In function `.a_wait_enum':
(.text.a_wait_enum+0x4c): undefined reference to `.otg_statemachine'
drivers/usb/phy/phy-fsl-usb.o: In function `.fsl_otg_set_peripheral':
phy-fsl-usb.c:(.text.fsl_otg_set_peripheral+0x84): undefined reference to 
`.usb_gadget_vbus_disconnect'
phy-fsl-usb.c:(.text.fsl_otg_set_peripheral+0x9c): undefined reference to 
`.otg_statemachine'



> Signed-off-by: Michael Ellerman 
> ---
>  arch/powerpc/Makefile | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 2556c2182789..48e887f03a6c 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -359,6 +359,16 @@ ppc32_allmodconfig:
>   $(Q)$(MAKE) 
> KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/book3s_32.config \
>   -f $(srctree)/Makefile allmodconfig
>  
> +PHONY += ppc64le_allmodconfig
> +ppc64le_allmodconfig:
> + $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/le.config 
> \
> + -f $(srctree)/Makefile allmodconfig
> +
> +PHONY += ppc64_book3e_allmodconfig
> +ppc64_book3e_allmodconfig:
> + $(Q)$(MAKE) 
> KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/85xx-64bit.config \
> + -f $(srctree)/Makefile allmodconfig
> +
>  define archhelp
>@echo '* zImage  - Build default images selected by kernel config'
>@echo '  zImage.*- Compressed kernel image 
> (arch/$(ARCH)/boot/zImage.*)'
> 

thanks,
-- 
~Randy

Re: CONFIG_ANDROID_BINDER_IPC=y (Re: powerpc: 32BIT vs. 64BIT (PPC32 vs. PPC64))

[Randy Dunlap]

On 07/13/2018 04:24 PM, Randy Dunlap wrote:
> On 07/13/2018 04:41 AM, Mathieu Malaterre wrote:
>> Randy,
>>
>> On Mon, Jul 9, 2018 at 2:00 PM Mathieu Malaterre  wrote:
>>>
>>> On Sun, Jul 8, 2018 at 1:53 PM Michael Ellerman  wrote:
>>>>
>>>> Randy Dunlap  writes:
>>>>> Hi,
>>>>>
>>>>> Is there a good way (or a shortcut) to do something like:
>>>>
>>>> The best I know of is:
>>>>
>>>>> $ make ARCH=powerpc O=PPC32 [other_options] allmodconfig
>>>>>   to get a PPC32/32BIT allmodconfig
>>>>
>>>> $ echo CONFIG_PPC64=n > allmod.config
>>>> $ KCONFIG_ALLCONFIG=1 make allmodconfig
>>>> $ grep PPC32 .config
>>>> CONFIG_PPC32=y
>>>>
>>>> Which is still a bit clunky.
>>>>
>>>>
>>>> I looked at this a while back and the problem we have is that the 32-bit
>>>> kernel is not a single thing. There are multiple 32-bit platforms which
>>>> are mutually exclusive.
>>>>
>>>> eg, from menuconfig:
>>>>
>>>>  - 512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx
>>>>  - Freescale 85xx
>>>>  - Freescale 8xx
>>>>  - AMCC 40x
>>>>  - AMCC 44x, 46x or 47x
>>>>  - Freescale e200
>>>
>>> Most Linux distro seems to have drop support for ppc32. So I'd suggest
>>> to pick Debian powperc default config (but I agree that I am a little
>>> biased here).
>>
>> I tried an allmode as suggest by Michael (above). But I get a build error:
>>
>>   MODPOST vmlinux.o
>> drivers/android/binder.o: In function `binder_thread_write':
>> binder.c:(.text+0xc750): undefined reference to `__get_user_bad'
>> binder.c:(.text+0xc76c): undefined reference to `__get_user_bad'
>> binder.c:(.text+0xc790): undefined reference to `__get_user_bad'
>> binder.c:(.text+0xc7d4): undefined reference to `__get_user_bad'
>> binder.c:(.text+0xc7f4): undefined reference to `__get_user_bad'
>>
>>
>> So for now I need to do: CONFIG_ANDROID_BINDER_IPC=n
>>
>> How did you get passed this build failure ?
> 
> Hi,
> 
> I am not seeing an error on that driver build.
> 
> I am using gcc 8.1.0 from kernel.org:
> https://mirrors.edge.kernel.org/pub/tools/crosstool/
> 
> and building on x86_64.

Hi Mathieu,

I do see this build error (slightly different undefined reference though)
when I do an arch/microblaze/ cross-build:

drivers/android/binder.o: In function `binder_thread_write':
drivers/android/.tmp_gl_binder.o:(.text+0xcba8): undefined reference to 
`__user_bad'
drivers/android/.tmp_gl_binder.o:(.text+0xcbd4): undefined reference to 
`__user_bad'
drivers/android/.tmp_gl_binder.o:(.text+0xcfbc): undefined reference to 
`__user_bad'
drivers/android/.tmp_gl_binder.o:(.text+0xd648): undefined reference to 
`__user_bad'
drivers/android/.tmp_gl_binder.o:(.text+0xdbc0): undefined reference to 
`__user_bad'


-- 
~Randy

[PATCH] scsi: prevent ISA driver from building on PPC32

[Randy Dunlap]

From: Randy Dunlap 

Prevent drivers from building on PPC32 if they use isa_bus_to_virt(),
isa_virt_to_bus(), or isa_page_to_bus(), which are not available and
thus cause build errors.

../drivers/scsi/aha1542.c: In function 'aha1542_queuecommand':
../drivers/scsi/aha1542.c:461:30: error: implicit declaration of function 
'isa_page_to_bus'; did you mean 'page_to_bus'? 
[-Werror=implicit-function-declaration]

Signed-off-by: Randy Dunlap 
Suggested-by: Michael Ellerman 
---
 drivers/scsi/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20180720.orig/drivers/scsi/Kconfig
+++ linux-next-20180720/drivers/scsi/Kconfig
@@ -428,7 +428,7 @@ config SCSI_AHA152X
 
 config SCSI_AHA1542
tristate "Adaptec AHA1542 support"
-   depends on ISA && SCSI && ISA_DMA_API
+   depends on ISA && SCSI && ISA_DMA_API && !PPC32
---help---
  This is support for a SCSI host adapter.  It is explained in section
  3.4 of the SCSI-HOWTO, available from

[PATCH] net: prevent ISA drivers from building on PPC32

[Randy Dunlap]

From: Randy Dunlap 

Prevent drivers from building on PPC32 if they use isa_bus_to_virt(),
isa_virt_to_bus(), or isa_page_to_bus(), which are not available and
thus cause build errors.

../drivers/net/ethernet/3com/3c515.c: In function 'corkscrew_open':
../drivers/net/ethernet/3com/3c515.c:824:9: error: implicit declaration of 
function 'isa_virt_to_bus'; did you mean 'virt_to_bus'? 
[-Werror=implicit-function-declaration]

../drivers/net/ethernet/amd/lance.c: In function 'lance_rx':
../drivers/net/ethernet/amd/lance.c:1203:23: error: implicit declaration of 
function 'isa_bus_to_virt'; did you mean 'bus_to_virt'? 
[-Werror=implicit-function-declaration]

../drivers/net/ethernet/amd/ni65.c: In function 'ni65_init_lance':
../drivers/net/ethernet/amd/ni65.c:585:20: error: implicit declaration of 
function 'isa_virt_to_bus'; did you mean 'virt_to_bus'? 
[-Werror=implicit-function-declaration]

../drivers/net/ethernet/cirrus/cs89x0.c: In function 'net_open':
../drivers/net/ethernet/cirrus/cs89x0.c:897:20: error: implicit declaration of 
function 'isa_virt_to_bus'; did you mean 'virt_to_bus'? 
[-Werror=implicit-function-declaration]

Signed-off-by: Randy Dunlap 
Suggested-by: Michael Ellerman 
---
in cirrus/Kconfig, CS89x0 should probably also depend on ISA_DMA_API.

 drivers/net/ethernet/3com/Kconfig   |2 +-
 drivers/net/ethernet/amd/Kconfig|4 ++--
 drivers/net/ethernet/cirrus/Kconfig |1 +
 3 files changed, 4 insertions(+), 3 deletions(-)

--- linux-next-20180720.orig/drivers/net/ethernet/3com/Kconfig
+++ linux-next-20180720/drivers/net/ethernet/3com/Kconfig
@@ -32,7 +32,7 @@ config EL3
 
 config 3C515
tristate "3c515 ISA \"Fast EtherLink\""
-   depends on ISA && ISA_DMA_API
+   depends on ISA && ISA_DMA_API && !PPC32
---help---
  If you have a 3Com ISA EtherLink XL "Corkscrew" 3c515 Fast Ethernet
  network card, say Y here.
--- linux-next-20180720.orig/drivers/net/ethernet/amd/Kconfig
+++ linux-next-20180720/drivers/net/ethernet/amd/Kconfig
@@ -44,7 +44,7 @@ config AMD8111_ETH
 
 config LANCE
tristate "AMD LANCE and PCnet (AT1500 and NE2100) support"
-   depends on ISA && ISA_DMA_API && !ARM
+   depends on ISA && ISA_DMA_API && !ARM && !PPC32
---help---
  If you have a network (Ethernet) card of this type, say Y here.
  Some LinkSys cards are of this type.
@@ -138,7 +138,7 @@ config PCMCIA_NMCLAN
 
 config NI65
tristate "NI6510 support"
-   depends on ISA && ISA_DMA_API && !ARM
+   depends on ISA && ISA_DMA_API && !ARM && !PPC32
---help---
  If you have a network (Ethernet) card of this type, say Y here.
 
--- linux-next-20180720.orig/drivers/net/ethernet/cirrus/Kconfig
+++ linux-next-20180720/drivers/net/ethernet/cirrus/Kconfig
@@ -19,6 +19,7 @@ if NET_VENDOR_CIRRUS
 config CS89x0
tristate "CS89x0 support"
depends on ISA || EISA || ARM
+   depends on !PPC32
---help---
  Support for CS89x0 chipset based Ethernet cards. If you have a
  network (Ethernet) card of this type, say Y and read the file

Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8

[Randy Dunlap]

On 07/24/2018 02:00 PM, Andrew Morton wrote:
> On Tue, 24 Jul 2018 13:13:25 +0200 Arnd Bergmann  wrote:
> 
>> Almost all files in the kernel are either plain text or UTF-8
>> encoded. A couple however are ISO_8859-1, usually just a few
>> characters in a C comments, for historic reasons.
>>
>> This converts them all to UTF-8 for consistency.
> 
> Was "consistency" the only rationale?  The discussion is now outside my
> memory horizon but I thought there were other reasons.

kconfig tools prefer ASCII or utf-8.

email tools probably likewise.

user sanity?

> Will we be getting a checkpatch rule to keep things this way?



-- 
~Randy

Re: [PATCH 0/6] rapidio: move Kconfig menu definition to subsystem

[Randy Dunlap]

On 07/30/2018 03:50 PM, Alexei Colin wrote:
> The top-level Kconfig entry for RapidIO subsystem is currently
> duplicated in several architecture-specific Kconfig files. This set of
> patches does two things:
> 
> 1. Move the Kconfig menu definition into the RapidIO subsystem and
> remove the duplicate definitions from arch Kconfig files.
> 
> 2. Enable RapidIO Kconfig menu entry for arm and arm64 architectures,
> where it was not enabled before. I tested that subsystem and drivers
> build successfully for both architectures, and tested that the modules
> load on a custom arm64 Qemu model.
> 
> For all architectures, RapidIO menu should be offered when either:
> (1) The platform has a PCI bus (which host a RapidIO module on the bus).
> (2) The platform has a RapidIO IP block (connected to a system bus, e.g.
> AXI on ARM). In this case, 'select HAS_RAPIDIO' should be added to the
> 'config ARCH_*' menu entry for the SoCs that offer the IP block.
> 
> Prior to this patchset, different architectures used different criteria:
> * powerpc: (1) and (2)
> * mips: (1) and (2) after recent commit into next that added (2):
>   https://www.linux-mips.org/archives/linux-mips/2018-07/msg00596.html
>   fc5d988878942e9b42a4de5204bdd452f3f1ce47
>   491ec1553e0075f345fbe476a93775eabcbc40b6
> * x86: (1)
> * arm,arm64: none (RapidIO menus never offered)
> 
> Responses to feedback from prior submission (thanks for the reviews!):
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-July/593347.html
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-July/593349.html
> 
> Changelog:
>   * Moved Kconfig entry into RapidIO subsystem instead of duplicating
> 
> In the current patchset, I took the approach of adding '|| PCI' to the
> depends in the subsystem. I did try the alterantive approach mentioned
> in the reviews for v1 of this patch, where the subsystem Kconfig does
> not add a '|| PCI' and each per-architecture Kconfig has to add a
> 'select HAS_RAPIDIO if PCI' and SoCs with IP blocks have to also add
> 'select HAS_RAPIDIO'. This works too but requires each architecture's
> Kconfig to add the line for RapidIO (whereas current approach does not
> require that involvement) and also may create a false impression that
> the dependency on PCI is strict.
> 
> We appreciate the suggestion for also selecting the RapdiIO subsystem for
> compilation with COMPILE_TEST, but hope to address it in a separate
> patchset, localized to the subsystem, since it will need to change
> depends on all drivers, not just on the top level, and since this
> patch now spans multiple architectures.
> 
> 
> Alexei Colin (6):
>   rapidio: define top Kconfig menu in driver subtree
>   x86: factor out RapidIO Kconfig menu
>   powerpc: factor out RapidIO Kconfig menu entry
>   mips: factor out RapidIO Kconfig entry
>   arm: enable RapidIO menu in Kconfig
>   arm64: enable RapidIO menu in Kconfig
> 
>  arch/arm/Kconfig|  2 ++
>  arch/arm64/Kconfig  |  2 ++
>  arch/mips/Kconfig   | 11 ---
>  arch/powerpc/Kconfig| 13 +
>  arch/x86/Kconfig|  8 
>  drivers/rapidio/Kconfig | 15 +++
>  6 files changed, 20 insertions(+), 31 deletions(-)
> 

LGTM.

Acked-by: Randy Dunlap  # for the series

thanks,
-- 
~Randy

[PATCH RESEND] powerpc: indent to improve Kconfig readability

[Randy Dunlap]

From: Randy Dunlap 

Indent a Kconfig continuation line to improve readability.

Signed-off-by: Randy Dunlap 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200128.orig/arch/powerpc/Kconfig
+++ linux-next-20200128/arch/powerpc/Kconfig
@@ -478,7 +478,7 @@ config MPROFILE_KERNEL
 config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
depends on SMP && (PPC_PSERIES || \
-   PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE)
+   PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE)
help
  Say Y here to be able to disable and re-enable individual
  CPUs at runtime on SMP machines.

Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

[Randy Dunlap]

[might be network related, so adding netdev mailing list]

On 2/1/20 4:08 PM, Christian Zigotzky wrote:
> Hello,
> 
> We regularly compile and test Linux kernels every day during the merge 
> window. Since Thuesday we have very high CPU loads because of the avahi 
> daemon on our desktop Linux systems (Ubuntu, Debian etc).
> 
> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
> 
> Could you please test the latest Git kernel?
> 
> It is possible to deactivate the avahi daemon with the following lines in the 
> file "/etc/avahi/avahi-daemon.conf":
> 
> use-ipv4=no
> use-ipv6=no
> 
> But this is only a temporary solution.
> 
> Thanks,
> Christian


-- 
~Randy

Re: [PATCH 0/3] Add new module driver for new ASRC

[Randy Dunlap]

On 2/11/20 8:30 PM, Shengjiu Wang wrote:
> Add new module driver for new ASRC in i.MX815/865
> 
> Shengjiu Wang (3):
>   ASoC: fsl_asrc: Move common definition to fsl_asrc_common
>   ASoC: dt-bindings: fsl_easrc: Add document for EASRC
>   ASoC: fsl_easrc: Add EASRC ASoC CPU DAI and platform drivers
> 
>  .../devicetree/bindings/sound/fsl,easrc.txt   |   57 +
>  sound/soc/fsl/fsl_asrc.h  |   11 +-
>  sound/soc/fsl/fsl_asrc_common.h   |   22 +
>  sound/soc/fsl/fsl_easrc.c | 2265 +
>  sound/soc/fsl/fsl_easrc.h |  668 +
>  sound/soc/fsl/fsl_easrc_dma.c |  440 
>  6 files changed, 3453 insertions(+), 10 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/sound/fsl,easrc.txt
>  create mode 100644 sound/soc/fsl/fsl_asrc_common.h
>  create mode 100644 sound/soc/fsl/fsl_easrc.c
>  create mode 100644 sound/soc/fsl/fsl_easrc.h
>  create mode 100644 sound/soc/fsl/fsl_easrc_dma.c
> 

Hi,

Is this patch series missing Kconfig, Makefile, and possibly
MAINTAINERS patches?

thanks.
-- 
~Randy

Re: linux-next bad Kconfig for drivers/hid

[Randy Dunlap]

On Thu, December 8, 2011 9:33 pm, Jeremy Fitzhardinge wrote:
> On 12/08/2011 05:27 PM, Tony Breeds wrote:
>> Commit 4f5ca836bef3 (HID: hid-input: add support for HID devices
>> reporting Battery Strength) went into linux-next on Dec 1st since then a
>> ppc6xx_defconfig has been failing with:
>>
>> ---
>> drivers/built-in.o: In function `hidinput_cleanup_battery':
>> /scratch/tony/working/drivers/hid/hid-input.c:351: undefined reference
>> to `power_supply_unregister'
>> drivers/built-in.o: In function `hidinput_setup_battery':
>> /scratch/tony/working/drivers/hid/hid-input.c:338: undefined reference
>> to `power_supply_register'
>> make[1]: *** [.tmp_vmlinux1] Error 1
>> ---
>>
>> http://kisskb.ellerman.id.au/kisskb/buildresult/5012563/
>> vs
>> http://kisskb.ellerman.id.au/kisskb/buildresult/5017366/
>>
>> The defconfig in question doens't mention either option
>> (CONFIG_POWER_SUPPLY or CONFIG_HID_BATTERY_STRENGTH) and kbuild is
>> genertaing
>> CONFIG_HID_BATTERY_STRENGTH=y
>> CONFIG_POWER_SUPPLY=m
>> which clearly isn't going to work.
>>
>> The following change to HID_BATTERY_STRENGTH Kconfig "works" but seems a
>> little gross.
>>
>> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
>> index 5ed64f6..d2a94e6 100644
>> --- a/drivers/hid/Kconfig
>> +++ b/drivers/hid/Kconfig
>> @@ -33,7 +33,7 @@ config HID
>>
>>  config HID_BATTERY_STRENGTH
>> bool
>> -   depends on POWER_SUPPLY
>> +   depends on POWER_SUPPLY=y
>> default y
>>
>>  config HIDRAW
>>
>> Any chance we can get a fix into linux-next?
>
> Hm.  How about making it "depends on HID && POWER_SUPPLY"?  I think that
> would needlessly disable it if HID is also modular, but I'm not sure how
> to fix that.  "depends on HID && POWER_SUPPLY && HID == POWER_SUPPLY"?

The last suggestion looks good to me.

-- 
~Randy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: linux-next bad Kconfig for drivers/hid

[Randy Dunlap]

On 12/15/2011 02:08 AM, Jiri Kosina wrote:
> On Mon, 12 Dec 2011, Tony Breeds wrote:
> 
>> On Mon, Dec 12, 2011 at 12:21:16AM +0100, Jiri Kosina wrote:
>>> On Thu, 8 Dec 2011, Jeremy Fitzhardinge wrote:

 Hm.  How about making it "depends on HID && POWER_SUPPLY"?  I think that
 would needlessly disable it if HID is also modular, but I'm not sure how
 to fix that.  "depends on HID && POWER_SUPPLY && HID == POWER_SUPPLY"?
>>
>> That would work, but I think technically I think you could end up with
>> HID=m and POWER_SUPPLY=m which would still allow HID_BATTERY_STRENGTH=y
>> which is the same problem.
>>
>> I don't know what kind of .config contortions you'd need to do to get
>> there.
>>  
>>> How about making it 'default POWER_SUPPLY' instead?
>>
>> By itself that wont help as POWER_SUPPLY=m statisfies.
>>
>> So it looks like we have Jeremy's:
>>  HID && POWER_SUPPLY && HID == POWER_SUPPLY
> 
> Tony,
> 
> have you actually tested this one to work in the configuration you have 
> been seeing it to fail?
> 
> I don't seem to be able to find any use of '==' in other Kconfig files 
> (and never used it myself), so I'd like to have confirmation that it 
> actually works and fixes the problem before I apply it :)

Documentation/kbuild/kconfig-language.txt does not list "==":

 ::=  (1)
'=' (2)
'!='(3)
   '('  ')'   (4)
   '!'(5)
'&&'(6)
'||'(7)


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] fsl/mpic: Document and use the "big-endian" device-tree flag

[Randy Dunlap]

On 12/22/2011 08:25 AM, Kyle Moffett wrote:
> The MPIC code checks for a "big-endian" property and sets the flag
> MPIC_BIG_ENDIAN if one is present.  Unfortunately, the PowerQUICC-III
> compatible device-tree does not specify it, so all of the board ports
> need to manually set that flag when calling mpic_alloc().
> 
> Document the flag and add it to the pq3 device tree.  Existing code
> will still need to pass the MPIC_BIG_ENDIAN flag because their dtb may
> not have this property, but new platforms shouldn't need to do so.
> 
> Signed-off-by: Kyle Moffett 

Grant, are you merging this patch?
I don't think I should merge the patch to 
arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi.

> ---
>  .../devicetree/bindings/powerpc/fsl/mpic.txt   |9 -
>  arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi|1 +
>  2 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt 
> b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
> index 2cf38bd..ebafba2 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
> @@ -56,7 +56,14 @@ PROPERTIES
>to the client.  The presence of this property also mandates
>that any initialization related to interrupt sources shall
>be limited to sources explicitly referenced in the device tree.
> -   
> +
> +  - big-endian
> +  Usage: optional
> +  Value type: 
> +  If present the MPIC will be assumed to be big-endian.  Some
> +  device-trees omit this property on MPIC nodes even when the MPIC is
> +  in fact big-endian, so certain boards override this property.
> +
>  INTERRUPT SPECIFIER DEFINITION
>  
>Interrupt specifiers consists of 4 cells encoded as
> diff --git a/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi 
> b/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
> index 5c80460..47f2b67 100644
> --- a/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
> @@ -39,6 +39,7 @@ mpic: pic@4 {
>   reg = <0x4 0x4>;
>   compatible = "fsl,mpic";
>   device_type = "open-pic";
> + big-endian;
>  };
>  
>  timer@41100 {


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC 0/14] Finish up irq_domain generalization

[Randy Dunlap]

On 01/11/2012 12:22 PM, Grant Likely wrote:
> Here are the patches that I've been working on to finish up the creation
> of the generic irq_domain infrastructure.

Does this fix the linux-next build problems that I have reported?

https://lkml.org/lkml/2012/1/9/318


>  kernel/irq/irqdomain.c   |  733 
> ++

thanks,
-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC 0/14] Finish up irq_domain generalization

[Randy Dunlap]

On 01/11/2012 01:23 PM, Grant Likely wrote:
> On Wed, Jan 11, 2012 at 1:50 PM, Grant Likely  
> wrote:
>> On Wed, Jan 11, 2012 at 2:39 PM, Randy Dunlap  wrote:
>>> On 01/11/2012 12:22 PM, Grant Likely wrote:
>>>> Here are the patches that I've been working on to finish up the creation
>>>> of the generic irq_domain infrastructure.
>>>
>>> Does this fix the linux-next build problems that I have reported?
>>>
>>> https://lkml.org/lkml/2012/1/9/318
>>
>> IIRC, that was solved and a fix merged.  The problem was a driver
>> selecting CONFIG_IRQ_DOMAIN when it must not do so.  I'm build testing
>> with that randconfig now to make sure.
> 
> Yes, doing oldconfig on that sample no longer has CONFIG_IRQ_DOMAIN
> selected, so it looks okay.

Thanks.  I never saw a patch for it.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFCv2 01/14] irq_domain: add documentation and MAINTAINERS entry.

[Randy Dunlap]

On 01/23/2012 01:07 PM, Grant Likely wrote:
> Documentation for irq_domain library which will be created in subsequent
> patches.
> 
> Signed-off-by: Grant Likely 
> Cc: Benjamin Herrenschmidt 
> Cc: Thomas Gleixner 
> ---
>  Documentation/IRQ-domain.txt |  113 
> ++
>  MAINTAINERS  |9 +++
>  2 files changed, 122 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/IRQ-domain.txt
> 
> diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt
> new file mode 100644
> index 000..247f32a
> --- /dev/null
> +++ b/Documentation/IRQ-domain.txt
> @@ -0,0 +1,113 @@
> +irq_domain interrupt number mapping library
> +
> +The current design of the Linux kernel uses a single large number
> +space where each separate IRQ source is assigned a different number.
> +This is simple when there is only one interrupt controller, but in
> +systems with controllers the kernel must ensure that each one does not

   with multiple interrupt controllers,

> +get assigned overlapping allocations of Linux irq numbers.

 IRQ

> +
> +The irq_alloc_desc*() and irq_free_desc*() API provides allocation of

I would say:  APIs provide

> +irq numbers, but it doesn't provide any support for reverse mapping of

   IRQ numbers, but they don't provide


> +the controller-local irq (hwirq) number into the Linux irq number

IRQ   IRQ

> +space.
> +
> +The irq_domain library adds mapping between hwirq and irq numbers on

 IRQ

> +top of the irq_alloc_desc*() API.  An irq_domain to manage mapping is
> +preferred over interrupt controller drivers open coding their own
> +reverse mapping scheme.
> +
> +irq_domain also implements translation from Device Tree interrupt
> +specifiers to hwirq numbers, and can be easily extended to support
> +other irq topology data sources.

 IRQ

> +
> +=== irq_domain usage ===
> +An interrupt controller driver creates and registers an irq_domain by
> +calling one of the irq_domain_add_*() functions (each mapping method
> +has a different allocator function, more on that later).  The function
> +will return a pointer to the irq_domain on success.  It must provide

"It" ?  The caller ?

> +the allocator function with an irq_domain_ops structure with the .map
> +callback populated as a minimum.
> +
> +In most cases, the irq_domain will begin empty without any mappings
> +between hwirq and irq numbers.  Mappings are added to the irq_domain

 IRQ

> +by calling irq_create_mapping() which accepts the irq_domain and a
> +hwirq number as arguments.  If a mapping for the hwirq doesn't already
> +exist then it will allocate a new linux irq_desc, associate it with

 Linux

> +the hwirq, and call the .map() callback so the driver can perform any
> +required hardware setup.
> +
> +When an interrupt is received, irq_find_mapping() function should
> +be used to find the Linux irq number from the hwirq number.

 IRQ

> +
> +If the driver has the Linux irq number or the irq_data pointer, and

   IRQ

> +needs to know the associated hwirq number (such as in the irq_chip
> +callbacks) then it can be directly obtained from irq_data->hwirq.
> +
> +=== Types of irq_domain mappings ===
> +There are several mechanisms available for reverse mapping from hwirq
> +to Linux irq, and each mechanism uses a different allocation function

IRQ,
.
> +Which reverse map type should be used depends on the use case.  Each
> +of the reverse map types are described below:
> +
> + Linear 
> +irq_domain_add_linear()
> +
> +The linear reverse map maintains a fixed size table indexed by the
> +hwirq number.  When a hwirq is mapped, an irq_desc is allocated for
> +the hwirq, and the irq number is stored in the table.

  IRQ

> +
> +The Linear map is a good choice when the maximum number of hwirqs is
> +fixed and a relatively small number (~ < 256).  The advantages of this
> +map are fixed time lookup for irq numbers, and irq_descs are only

 IRQ

> +allocated for in-use irqs.  The disadvantage is that the table must be
> +as large as the largest possible hwirq number.
> +
> +The majority of drivers should use the linear map.
> +
> + Tree 
> +irq_domain_add_tree()
> +
> +The irq_domain maintains a radix tree map from hwirq numbers to linux

   Linux

> +irqs.  When an hwirq is mapped, and irq_desc is allocated and the

   IRQs.  When a hwirq an

> +hwirq is used as the lookup key for the radix tree.
> +
> +The tree map is a good choice if the hwirq number ca

Re: [PATCH v3 01/25] irq_domain: add documentation and MAINTAINERS entry.

[Randy Dunlap]

On 01/27/2012 01:35 PM, Grant Likely wrote:
> Documentation for irq_domain library which will be created in subsequent
> patches.

I posted a lot of comments to v2 on Jan. 24.
Looks like they were ignored.

Please see  http://marc.info/?l=linuxppc-embedded&m=132742951211808&w=2


> Signed-off-by: Grant Likely 
> Cc: Benjamin Herrenschmidt 
> Cc: Thomas Gleixner 
> Cc: Rob Herring 
> Cc: Milton Miller 
> ---
>  Documentation/IRQ-domain.txt |  113 
> ++
>  MAINTAINERS  |9 +++
>  2 files changed, 122 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/IRQ-domain.txt


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFC] Simplify the Linux kernel by reducing its state space

[Randy Dunlap]

On 03/31/2012 01:15 PM, Linas Vepstas wrote:

> 
> Hi,
> 
> I didn't actually try to compile the patch below; it didn't look like
> C code so I wasn't sure what compiler to run it through.  I guess maybe
> its python?  However, I'm very sure that the patches are completely
> correct, because I read them, and I also know Paul.  And I've heard of
> Thomas Gleixner.


x86_64 defconfig has many build errors and warnings.  :(

back to my abacus.

-- 
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] net: of/phy: fix build error when phylib is built as a module

[Randy Dunlap]

On 05/11/2012 08:47 AM, Bjørn Mork wrote:

> CONFIG_OF_MDIO is tristate and will be m if PHYLIB is m.  Use
> IS_ENABLED macro to prevent build error:
> 
>  ERROR: "of_mdio_find_bus" [drivers/net/phy/mdio-mux.ko] undefined!
> 
> Reported-by: Randy Dunlap 
> Cc: David Daney 
> Signed-off-by: Bjørn Mork 


Acked-by: Randy Dunlap 

Thanks.


> ---
> I wonder if this could be as banal as this?  Not even build tested...
> 
> Should be wrapped into commit 25106022 if it works, to ensure
> bisectability.
> 
> 
> 
> Bjørn
> 
>  drivers/net/phy/mdio_bus.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 83d5c9f..683ef1c 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -88,7 +88,7 @@ static struct class mdio_bus_class = {
>   .dev_release= mdiobus_release,
>  };
>  
> -#ifdef CONFIG_OF_MDIO
> +#if IS_ENABLED(CONFIG_OF_MDIO)
>  /* Helper function for of_mdio_find_bus */
>  static int of_mdio_bus_match(struct device *dev, void *mdio_bus_np)
>  {



-- 
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] video, sm501: add OF binding to support SM501

[Randy Dunlap]

On Sat, 11 Dec 2010 07:31:15 +0100 Heiko Schocher wrote:

> - add commandline options:
>   sm501.fb_mode:

sm501.mode:

> Specify resolution as "x[-][@]"
>   sm501.bpp:
> Specify bit-per-pixel if not specified mode
> 
> ---
> 
>  Documentation/kernel-parameters.txt  |7 +
>  Documentation/powerpc/dts-bindings/sm501.txt |   30 +++
>  drivers/mfd/sm501.c  |  141 --
>  drivers/video/sm501fb.c  |  264 
> +-
>  include/linux/sm501.h|8 +
>  5 files changed, 299 insertions(+), 151 deletions(-)
>  create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index cdd2a6e..6341541 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2301,6 +2301,13 @@ and is between 256 and 4096 characters. It is defined 
> in the file
>   merging on their own.
>   For more information see Documentation/vm/slub.txt.
>  
> + sm501.bpp=  SM501 Display driver:
> + Specify bit-per-pixel if not specified mode

Specifiy bits-per-pixel if not specified by 'mode'

> +
> + sm501fb.mode=   SM501 Display driver:
> + Specify resolution as
> + "x[-][@]"
> +
>   smart2= [HW]
>   Format: [,[,...,]]


However, I think that these shouldn't be added to 
Documentation/kernel-parameters.txt
but should be added to the Documentation/fb/ sub-directory either by adding to
Documentation/fb/modedb.txt or by adding a new file Documentation/fb/sm501.txt.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] video, sm501: add OF binding to support SM501

[Randy Dunlap]

On Sat, 11 Dec 2010 07:31:15 +0100 Heiko Schocher wrote:

> - add commandline options:
>   sm501.fb_mode:

sm501.mode:

> Specify resolution as "x[-][@]"
>   sm501.bpp:
> Specify bit-per-pixel if not specified mode
> 
> ---
> 
>  Documentation/kernel-parameters.txt  |7 +
>  Documentation/powerpc/dts-bindings/sm501.txt |   30 +++
>  drivers/mfd/sm501.c  |  141 --
>  drivers/video/sm501fb.c  |  264 
> +-
>  include/linux/sm501.h|8 +
>  5 files changed, 299 insertions(+), 151 deletions(-)
>  create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index cdd2a6e..6341541 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2301,6 +2301,13 @@ and is between 256 and 4096 characters. It is defined 
> in the file
>   merging on their own.
>   For more information see Documentation/vm/slub.txt.
>  
> + sm501.bpp=  SM501 Display driver:
> + Specify bit-per-pixel if not specified mode

Specifiy bits-per-pixel if not specified by 'mode'

> +
> + sm501fb.mode=   SM501 Display driver:

Shouldn't that be sm501.mode ?

> + Specify resolution as
> + "x[-][@]"
> +
>   smart2= [HW]
>   Format: [,[,...,]]


However, I think that these shouldn't be added to 
Documentation/kernel-parameters.txt
but should be added to the Documentation/fb/ sub-directory either by adding to
Documentation/fb/modedb.txt or by adding a new file Documentation/fb/sm501.txt.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v10 09/10] USB/ppc4xx:Synopsys DWC OTG driver enable gadget support

[Randy Dunlap]

> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> index bc5123c..61aca75 100644
> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -365,6 +365,28 @@ config USB_GADGET_MUSB_HDRC
> This OTG-capable silicon IP is used in dual designs including
> the TI DaVinci, OMAP 243x, OMAP 343x, TUSB 6010, and ADI Blackfin
>  
> +# dwc_otg builds in ../dwc_otg along with host support
> +config USB_GADGET_DWC_HDRC
> + boolean "DesignWare USB Peripheral"
> + depends on DWC_OTG_MODE || DWC_DEVICE_ONLY
> + select USB_GADGET_DUALSPEED
> + select USB_GADGET_SELECTED
> + select USB_GADGET_DWC_OTG
> + help
> + This OTG-capable Designware USB IP

missing complete help text.

> +
> +config USB_GADGET_DWC_OTG
> + boolean "OTG Support"
> + depends on USB_GADGET_DWC_HDRC
> + help
> + The most notable feature of USB OTG is support for a
> + "Dual-Role" device, which can act as either a device
> + or a host.  The initial role choice can be changed
> + later, when two dual-role devices talk to each other.
> + Select this only if your board has a Mini-AB connector.
> +
> +
> +
>  config USB_GADGET_M66592
>   boolean "Renesas M66592 USB Peripheral Controller"
>   select USB_GADGET_DUALSPEED


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 2/3] cpu: Offline state Framework.

[Randy Dunlap]

On Tue, 15 Sep 2009 17:37:06 +0530 Gautham R Shenoy wrote:

> Signed-off-by: Gautham R Shenoy 
> ---
>  Documentation/cpu-hotplug.txt |   22 +
>  drivers/base/cpu.c|  181 
> +++--
>  include/linux/cpu.h   |   10 ++
>  3 files changed, 204 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
> index 9d620c1..dcec06d 100644
> --- a/Documentation/cpu-hotplug.txt
> +++ b/Documentation/cpu-hotplug.txt
> @@ -115,6 +115,28 @@ Just remember the critical section cannot call any
>  function that can sleep or schedule this process away. The preempt_disable()
>  will work as long as stop_machine_run() is used to take a cpu down.
>  
> +CPU-offline states
> +--
> +On architectures which allow the more than one valid state when

^drop "the"

> +the CPU goes offline, the system administrator can decide
> +the state the CPU needs to go to when it is offlined.

s/needs to/should/

> +
> +If the architecture has implemented a cpu-offline driver exposing these
> +multiple offline states, the system administrator can use the following sysfs
> +interfaces to query the available hotplug states and also query and set the
> +current hotplug state for a given cpu:
> +
> +To query the hotplug states, on needs to perform a read on:

one

> +/sys/devices/system/cpu/cpu/available_hotplug_states
> +
> +To query or set the current state for a particular CPU,
> +one needs to use the sysfs interface
> +
> +/sys/devices/system/cpu/cpu/current_hotplug_state
> +
> +Writes to the "online" sysfs files are serialized against the writes to the
> +"current_hotplug_state" file.
> +
>  CPU Hotplug - Frequently Asked Questions.
>  
>  Q: How to enable my kernel to support CPU hotplug?


---
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [BUILD FAILURE 11/12] Next April 21 : PPC64 randconfig [drivers/usb/host/ohci-hcd.o]

[Randy Dunlap]

Kumar Gala wrote:
> 
> On Apr 21, 2009, at 2:03 PM, David Brownell wrote:
> 
>> On Tuesday 21 April 2009, Subrata Modak wrote:
>>> Observing this for the first time:
>>>
>>> CC  drivers/usb/host/ohci-hcd.o
>>> In file included from drivers/usb/host/ohci-hcd.c:1060:
>>> drivers/usb/host/ohci-ppc-of.c:242:2: error: #error "No endianess
>>
>> Hmm, scripts/get_maintainer.pl doesn't report
>> the PPC folk who maintain that file and its
>> kbuild infrastructure.
>>
>> Can we have some PPC folk look at (and fix) this?
> 
> The problem is in the drivers/usb/host/Kconfig:
> 
> config USB_OHCI_HCD_PPC_OF_BE
> bool "Support big endian HC"
> depends on USB_OHCI_HCD_PPC_OF
> default y
> select USB_OHCI_BIG_ENDIAN_DESC
> select USB_OHCI_BIG_ENDIAN_MMIO
> 
> config USB_OHCI_HCD_PPC_OF_LE
> bool "Support little endian HC"
> depends on USB_OHCI_HCD_PPC_OF
> default n
> select USB_OHCI_LITTLE_ENDIAN
> 
> Since its feasible to say 'n' to both we get the compile error.  How do
> we enforce having at least one set?

Looks like using "choice" without "optional" would do it.
See Documentation/kbuild/kconfig-language.txt and various examples
in Kconfig* files.

-- 
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [BUILD FAILURE 11/12] Next April 21 : PPC64 randconfig [drivers/usb/host/ohci-hcd.o]

[Randy Dunlap]

David Brownell wrote:
> On Tuesday 21 April 2009, Randy Dunlap wrote:
>>> Since its feasible to say 'n' to both we get the compile error.  How do
>>> we enforce having at least one set?
>> Looks like using "choice" without "optional" would do it.
>> See Documentation/kbuild/kconfig-language.txt and various examples
>> in Kconfig* files.
> 
> That won't quite work ... "at least one" includes "two"
> (i.e. a PCI card in little-endian, a native controller
> in big-endian).  Real-world systems need such configs,
> or so I'm told, and that's why their supported.

Yes, I see.

> Is there maybe a way to force Kconfig to just reject
> such illegal configs -- neither option set -- rather
> than trying some how to fix it?

Not that I know of.  cc-ing Sam.

> Or maybe ... if neither one is set, have the header
> force both on, and issue a warning.

That should be doable.  We'd prefer to catch it via Kconfig,
but that doesn't look promising just now.

-- 
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [BUILD FAILURE 09/12] Next April 21 : PPC64 randconfig [drivers/staging/comedi/drivers.o]

[Randy Dunlap]

Geert Uytterhoeven wrote:
> On Wed, 22 Apr 2009, Michael Ellerman wrote:
>> On Wed, 2009-04-22 at 00:23 +0530, Subrata Modak wrote:
>>> Reported this error on 14th April:
>>> http://lkml.org/lkml/2009/4/14/488,
>>>
>>> CC [M]  drivers/staging/comedi/drivers.o 
>>> drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’:
>>> drivers/staging/comedi/drivers.c:496: error: ‘PAGE_KERNEL_NOCACHE’
>>> undeclared (first use in this function)
>>> drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier
>>> is reported only once
>>> drivers/staging/comedi/drivers.c:496: error: for each function it
>>> appears in.)
>>> make[3]: *** [drivers/staging/comedi/drivers.o] Error 1
>>> make[2]: *** [drivers/staging/comedi] Error 2
>>> make[1]: *** [drivers/staging] Error 2
>>> make: *** [drivers] Error 2
>> Subrata, unless someone says otherwise, please do not send randconfig
>> failures for drivers in staging - those drivers have bigger problems
>> than randconfig failures.
> 
> Indeed, in particular this one http://lkml.org/lkml/2009/3/9/349.
> 
>> To avoid them, do this:
>>
>> # make randconfig
>> # sed -i -e 's/^\(CONFIG_STAGING\)=y/# \1 is not set/' .config
>^^^
> Recently I discovered that `n' actually works, too!

Yes, I've been using =n for quite awhile to disable a config symbol.

>> # make oldconfig


-- 
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH][BUILD FAILURE 03/12] Re: Next April 21 : PPC64 randconfig [arch/powerpc/kernel/of_platform.o]

[Randy Dunlap]

Michael Ellerman wrote:
> On Wed, 2009-04-22 at 21:46 +0530, Subrata Modak wrote:
>> On Wed, 2009-04-22 at 00:20 +0530, Subrata Modak wrote:
>>> Reported this earlier on 14th April 2009:
>>> http://lkml.org/lkml/2009/4/14/480,
>>>
>>> Michael,
>>>
>>> Any fix in sight ?
>>> http://lkml.org/lkml/2009/4/14/676,
>>>
>>> CC  arch/powerpc/kernel/of_platform.o
>>> arch/powerpc/kernel/of_platform.c: In function 'of_pci_phb_probe':
>>> arch/powerpc/kernel/of_platform.c:270: error: implicit declaration of
>>> function 'pci_devs_phb_init_dynamic'
>>> arch/powerpc/kernel/of_platform.c:279: error: implicit declaration of
>>> function 'scan_phb'
>>> arch/powerpc/kernel/of_platform.c:295: error: implicit declaration of
>>> function 'pci_bus_add_devices'
>>> make[1]: *** [arch/powerpc/kernel/of_platform.o] Error 1
>>> make: *** [arch/powerpc/kernel] Error 2
>>> ---
> 
> The problem above is as I said before, that the Cell Kconfig forces on
> PPC_OF_PLATFORM_PCI even if PCI is disabled. I think the proper fix is
> just to have CELL_NATIVE force on PCI.
> 
> I don't know how you got the other errors, both pci_dn.c and pci_dlpar.c
> are only built if CONFIG_PCI is enabled, see the Makefiles.


The Kconfig could be more like this:
config PPC_CELL_NATIVE
bool
select PPC_CELL_COMMON
-   select PPC_OF_PLATFORM_PCI
+   select PPC_OF_PLATFORM_PCI if PCI

if it would help...



-- 
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] ps3_gelic_wireless: Fix build failure due to missing WEXT_PRIV

[Randy Dunlap]

On Fri, 18 Dec 2009 16:52:54 +1100 Benjamin Herrenschmidt wrote:

> The option to support the old style PSK interface in the PS3
> GELIC wireless drivers requires CONFIG_WEXT_PRIV to be set
> 
> Signed-off-by: Benjamin Herrenschmidt 
> ---
> 
> Please send to Linus asap (or I can put it in powerpc.git) as it's
> breaking one of my test build configs :-)
> 
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index e58a653..c0ecc77 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2358,6 +2358,7 @@ config GELIC_WIRELESS
>  config GELIC_WIRELESS_OLD_PSK_INTERFACE
> bool "PS3 Wireless private PSK interface (OBSOLETE)"
> depends on GELIC_WIRELESS
> +   select WEXT_PRIV
> help
>This option retains the obsolete private interface to pass
>the PSK from user space programs to the driver.  The PSK

Probably also needs
depends on WLAN
to prevent build failures.

---
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/4] Some typo fixing

[Randy Dunlap]

On 03/15/10 13:55, Thomas Weber wrote:
> I have fixed some typos.

Acked-by: Randy Dunlap 

Jiri, can you merge these, please, unless someone objects (?).


> Thomas Weber (4):
>   Fix typo: [Ss]ytem => [Ss]ystem
>   Fix typo: udpate => update
>   Fix typo: paramters => parameters
>   Fix typo: orginal => original
> 
>  Documentation/cgroups/cgroups.txt   |2 +-
>  Documentation/kbuild/kconfig.txt|2 +-
>  Documentation/sysfs-rules.txt   |2 +-
>  Documentation/trace/events.txt  |8 
>  drivers/acpi/osl.c  |4 ++--
>  drivers/ata/ata_piix.c  |2 +-
>  drivers/firewire/ohci.c |2 +-
>  drivers/gpu/drm/drm_bufs.c  |2 +-
>  drivers/infiniband/hw/ipath/ipath_iba6110.c |2 +-
>  drivers/infiniband/hw/ipath/ipath_iba6120.c |4 ++--
>  drivers/infiniband/hw/ipath/ipath_iba7220.c |2 +-
>  drivers/isdn/hisax/hfc4s8s_l1.c |2 +-
>  drivers/macintosh/windfarm_pm81.c   |2 +-
>  drivers/media/dvb/dvb-usb/friio-fe.c|2 +-
>  drivers/net/smsc911x.c  |4 ++--
>  drivers/pci/hotplug/cpqphp_core.c   |2 +-
>  drivers/pci/pci.c   |2 +-
>  drivers/ps3/ps3-sys-manager.c   |2 +-
>  drivers/regulator/core.c|2 +-
>  drivers/s390/char/sclp_cpi_sys.c|2 +-
>  drivers/scsi/bfa/include/defs/bfa_defs_cee.h|2 +-
>  drivers/scsi/bfa/include/defs/bfa_defs_status.h |4 ++--
>  drivers/spi/spi_mpc8xxx.c   |2 +-
>  drivers/staging/iio/Documentation/overview.txt  |2 +-
>  drivers/staging/rt2860/rtmp.h   |2 +-
>  drivers/staging/rtl8187se/r8180_core.c  |4 ++--
>  drivers/staging/rtl8187se/r8180_dm.c|2 +-
>  drivers/staging/rtl8187se/r8185b_init.c |2 +-
>  drivers/virtio/virtio_pci.c |2 +-
>  fs/jfs/jfs_dmap.c   |2 +-
>  kernel/cgroup.c |2 +-
>  mm/page_alloc.c |2 +-
>  net/wimax/op-rfkill.c   |2 +-
>  sound/pci/emu10k1/emu10k1_main.c|2 +-
>  34 files changed, 42 insertions(+), 42 deletions(-)
> 

Thanks.

-- 
~Randy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v21 011/100] eclone (11/11): Document sys_eclone

[Randy Dunlap]

On Sat,  1 May 2010 10:14:53 -0400 Oren Laadan wrote:

> From: Sukadev Bhattiprolu 
> 
> This gives a brief overview of the eclone() system call.  We should
> eventually describe more details in existing clone(2) man page or in
> a new man page.
> 
> Signed-off-by: Sukadev Bhattiprolu 
> Acked-by: Serge E. Hallyn 
> Acked-by: Oren Laadan  
> ---
>  Documentation/eclone |  348 
> ++
>  1 files changed, 348 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/eclone
> 
> diff --git a/Documentation/eclone b/Documentation/eclone
> new file mode 100644
> index 000..c2f1b4b
> --- /dev/null
> +++ b/Documentation/eclone
> @@ -0,0 +1,348 @@
> +
> +struct clone_args {
> + u64 clone_flags_high;
> + u64 child_stack;
> + u64 child_stack_size;
> + u64 parent_tid_ptr;
> + u64 child_tid_ptr;
> + u32 nr_pids;
> + u32 reserved0;
> +};
> +
> +
> +sys_eclone(u32 flags_low, struct clone_args * __user cargs, int cargs_size,
> + pid_t * __user pids)
> +
> + In addition to doing everything that clone() system call does, the

that the clone()

> + eclone() system call:
> +
> + - allows additional clone flags (31 of 32 bits in the flags
> +   parameter to clone() are in use)
> +
> + - allows user to specify a pid for the child process in its
> +   active and ancestor pid namespaces.
> +
> + This system call is meant to be used when restarting an application
> + from a checkpoint. Such restart requires that the processes in the
> + application have the same pids they had when the application was
> + checkpointed. When containers are nested, the processes within the
> + containers exist in multiple pid namespaces and hence have multiple
> + pids to specify during restart.
> +
> + The @flags_low parameter is identical to the 'clone_flags' parameter
> + in existing clone() system call.

in the existing

> +
> + The fields in 'struct clone_args' are meant to be used as follows:
> +
> + u64 clone_flags_high:
> +
> + When eclone() supports more than 32 flags, the additional bits
> + in the clone_flags should be specified in this field. This
> + field is currently unused and must be set to 0.
> +
> + u64 child_stack;
> + u64 child_stack_size;
> +
> + These two fields correspond to the 'child_stack' fields in
> + clone() and clone2() (on IA64) system calls. The usage of
> + these two fields depends on the processor architecture.
> +
> + Most architectures use ->child_stack to pass-in a stack-pointer

 to pass in

> + itself and don't need the ->child_stack_size field. On these
> + architectures the ->child_stack_size field must be 0.
> +
> + Some architectures, eg IA64, use ->child_stack to pass-in the

e.g.to pass in

> + base of the region allocated for stack. These architectures
> + must pass in the size of the stack-region in ->child_stack_size.

 stack region

Seems unfortunate that different architectures use the fields differently.

> +
> + u64 parent_tid_ptr;
> + u64 child_tid_ptr;
> +
> + These two fields correspond to the 'parent_tid_ptr' and
> + 'child_tid_ptr' fields in the clone() system call

  system call.

> +
> + u32 nr_pids;
> +
> + nr_pids specifies the number of pids in the @pids array
> + parameter to eclone() (see below). nr_pids should not exceed
> + the current nesting level of the calling process (i.e if the

  i.e.

> + process is in init_pid_ns, nr_pids must be 1, if process is
> + in a pid namespace that is a child of init-pid-ns, nr_pids
> + cannot exceed 2, and so on).
> +
> + u32 reserved0;
> + u64 reserved1;
> +
> + These fields are intended to extend the functionality of the
> + eclone() in the future, while preserving backward compatibility.
> + They must be set to 0 for now.

The struct does not have a reserved1 field AFAICT.

> + The @cargs_size parameter specifes the sizeof(struct clone_args) and
> + is intended to enable extending this structure in the future, while
> + preserving backward compatibility.  For now, this field must be set
> + to the sizeof(struct clone_args) and this size must match the kernel's
> + view of the structure.
> +
> + The @pids parameter defines the set of pids that should be assigned to
> + the child process in its active and ancestor pid 

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On Wed, 8 Jun 2011 17:45:54 -0500 Timur Tabi wrote:

> Add the drivers/virt directory, which houses drivers that support
> virtualization environments, and add the Freescale hypervisor management
> driver.

It can't go in linux/virt or linux/virt/fsl instead?  why drivers/ ?

or maybe linux/virt should be drivers/virt ?


> The Freescale hypervisor management driver provides several services to
> drivers and applications related to the Freescale hypervisor:
> 
> 1. An ioctl interface for querying and managing partitions
> 
> 2. A file interface to reading incoming doorbells
> 
> 3. An interrupt handler for shutting down the partition upon receiving the
>shutdown doorbell from a manager partition
> 
> 4. An interface for receiving callbacks when a managed partition shuts down.
> 
> Signed-off-by: Timur Tabi 
> ---
>  drivers/Kconfig|2 +
>  drivers/Makefile   |3 +
>  drivers/virt/Kconfig   |   22 +
>  drivers/virt/Makefile  |5 +
>  drivers/virt/fsl_hypervisor.c  |  961 
> 
>  include/linux/Kbuild   |1 +
>  include/linux/fsl_hypervisor.h |  214 +
>  7 files changed, 1208 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/virt/Kconfig
>  create mode 100644 drivers/virt/Makefile
>  create mode 100644 drivers/virt/fsl_hypervisor.c
>  create mode 100644 include/linux/fsl_hypervisor.h


> diff --git a/include/linux/fsl_hypervisor.h b/include/linux/fsl_hypervisor.h
> new file mode 100644
> index 000..4d1e11a
> --- /dev/null
> +++ b/include/linux/fsl_hypervisor.h
> @@ -0,0 +1,214 @@
> +/*
> + * Freescale hypervisor ioctl interface
> + *
> + * Copyright (C) 2008-2011 Freescale Semiconductor, Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are 
> met:
> + * * Redistributions of source code must retain the above copyright
> + *   notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + *   notice, this list of conditions and the following disclaimer in the
> + *   documentation and/or other materials provided with the distribution.
> + * * Neither the name of Freescale Semiconductor nor the
> + *   names of its contributors may be used to endorse or promote products
> + *   derived from this software without specific prior written 
> permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of the
> + * GNU General Public License ("GPL") as published by the Free Software
> + * Foundation, either version 2 of that License or (at your option) any
> + * later version.

Why any later version?  I thought that  decided that Linux
is GPL v2.

> + *
> + * This software is provided by Freescale Semiconductor "as is" and any
> + * express or implied warranties, including, but not limited to, the implied
> + * warranties of merchantability and fitness for a particular purpose are
> + * disclaimed. In no event shall Freescale Semiconductor be liable for any
> + * direct, indirect, incidental, special, exemplary, or consequential damages
> + * (including, but not limited to, procurement of substitute goods or 
> services;
> + * loss of use, data, or profits; or business interruption) however caused 
> and
> + * on any theory of liability, whether in contract, strict liability, or tort
> + * (including negligence or otherwise) arising in any way out of the use of 
> this
> + * software, even if advised of the possibility of such damage.
> + *
> + * This file is used by the Freescale hypervisor management driver.  It can
> + * also be included by applications that need to communicate with the driver
> + * via the ioctl interface.
> + */
> +
> +#ifndef FSL_HYPERVISOR_H
> +#define FSL_HYPERVISOR_H
> +
> +#include 
> +
> +/**
> + * struct fsl_hv_ioctl_restart: restart a partition

This syntax should be (for all structs here):

 * struct fsl_hv_ioctl_restart - restart a partition

but the struct fields/members do use ':' instead of '-'.

Darn, I checked Documentation/kernel-doc-nano-HOWTO.txt and it says
that ':' is optional but '-' is needed, so you could use

 * struct fsl_hv_ioctl_restart: - restart a partition

> + * @ret: return error code from the hypervisor
> + * @partition: the ID of the partition to restart, or -1 for the
> + * calling partition
> + *
> + * Used by FSL_HV_IOCTL_PARTITION_RESTART
> + */
> +struct fsl_hv_ioctl_restart {
> + __u32 ret;
> + __u32 partition;
> +};
> +
> +/**
> + * struct fsl_hv_ioctl_status: get a partition's status
> + * @ret: return error code from the hypervisor
> + * @partition: the ID of the partition to query, or -1 for the
> + * calling partition
> + * @status: The returned status of the partition
> + *
> + * Used by FSL_HV_IOCTL_PARTITION_GET_STATUS
> + *
> + * Values of 'sta

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On 06/09/11 00:38, Arnd Bergmann wrote:
> On Thursday 09 June 2011 01:10:09 Randy Dunlap wrote:
>> On Wed, 8 Jun 2011 17:45:54 -0500 Timur Tabi wrote:
>>
>>> Add the drivers/virt directory, which houses drivers that support
>>> virtualization environments, and add the Freescale hypervisor management
>>> driver.
>>
>> It can't go in linux/virt or linux/virt/fsl instead?  why drivers/ ?
>>
>> or maybe linux/virt should be drivers/virt ?
> 
> See discussion for v2 of this patch. I suggested that drivers/firmware and 
> virt/
> as options, the counterarguments were that drivers/firmware is for passive
> firmware as opposed to firmware that acts as a hypervisor, and that virt/ is
> for the host side of hypervisors like kvm, not for guests.

OK, I read that thread.  Didn't see a real consensus there.

If you were not the drivers/misc/ maintainer, would you mind if this
driver lived in drivers/misc/?  I wouldn't.

But it sounds like virt/ needs virt/host/ and virt/guest/ to me.


> The driver in here most closely resembles the xen dom0 model, where a
> priviledged guest controls other guests, but unlike xen there is a single
> driver file, so there is no need to have drivers/fsl-hv directory just
> for this one file. We do have a number of other hypervisors that fit in the
> same category, so they can be added here later.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On 06/09/11 09:36, Timur Tabi wrote:
> Randy Dunlap wrote:
>> But it sounds like virt/ needs virt/host/ and virt/guest/ to me.
> 
> I'm okay with that idea, except there's a consensus that drivers should be in
> drivers/.
> 

Like sound/ ?

but what makes it a "driver"?

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On Thu, 9 Jun 2011 14:13:14 -0500 Timur Tabi wrote:

> Add the drivers/virt directory, which houses drivers that support
> virtualization environments, and add the Freescale hypervisor management
> driver.
> 
> The Freescale hypervisor management driver provides several services to
> drivers and applications related to the Freescale hypervisor:
> 
> 1. An ioctl interface for querying and managing partitions
> 
> 2. A file interface to reading incoming doorbells
> 
> 3. An interrupt handler for shutting down the partition upon receiving the
>shutdown doorbell from a manager partition
> 
> 4. A kernel interface for receiving callbacks when a managed partition
>shuts down.
> 
> Signed-off-by: Timur Tabi 
> ---
>  drivers/Kconfig|2 +
>  drivers/Makefile   |3 +
>  drivers/virt/Kconfig   |   32 ++
>  drivers/virt/Makefile  |5 +
>  drivers/virt/fsl_hypervisor.c  |  983 
> 
>  include/linux/Kbuild   |1 +
>  include/linux/fsl_hypervisor.h |  231 ++
>  7 files changed, 1257 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/virt/Kconfig
>  create mode 100644 drivers/virt/Makefile
>  create mode 100644 drivers/virt/fsl_hypervisor.c
>  create mode 100644 include/linux/fsl_hypervisor.h

> diff --git a/include/linux/fsl_hypervisor.h b/include/linux/fsl_hypervisor.h
> new file mode 100644
> index 000..d1ca2b1
> --- /dev/null
> +++ b/include/linux/fsl_hypervisor.h
> @@ -0,0 +1,231 @@

[snip]

> +/**
> + * enum fsl_hv_ioctl_cmd - ioctl commands
> + * @FSL_HV_IOCTL_PARTITION_RESTART: restart another partition
> + * @FSL_HV_IOCTL_PARTITION_GET_STATUS: get a partition's status
> + * @FSL_HV_IOCTL_PARTITION_START: boot another partition
> + * @FSL_HV_IOCTL_PARTITION_STOP: stop this or another partition
> + * @FSL_HV_IOCTL_MEMCPY: copy data from one partition to another
> + * @FSL_HV_IOCTL_DOORBELL: ring a doorbell
> + * @FSL_HV_IOCTL_GETPROP: get a property from another guest's device tree
> + * @FSL_HV_IOCTL_SETPROP: set a property in another guest's device tree
> + *
> + * This enum lists the available ioctl commands for the Freescale hypervisor
> + * management driver.  The meaning
> + */
> +enum fsl_hv_ioctl_cmd {
> + FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct 
> fsl_hv_ioctl_restart),
> + FSL_HV_IOCTL_PARTITION_GET_STATUS = _IOWR(0, 2, struct 
> fsl_hv_ioctl_status),
> + FSL_HV_IOCTL_PARTITION_START = _IOWR(0, 3, struct fsl_hv_ioctl_start),
> + FSL_HV_IOCTL_PARTITION_STOP = _IOWR(0, 4, struct fsl_hv_ioctl_stop),
> + FSL_HV_IOCTL_MEMCPY = _IOWR(0, 5, struct fsl_hv_ioctl_memcpy),
> + FSL_HV_IOCTL_DOORBELL = _IOWR(0, 6, struct fsl_hv_ioctl_doorbell),
> + FSL_HV_IOCTL_GETPROP = _IOWR(0, 7, struct fsl_hv_ioctl_prop),
> + FSL_HV_IOCTL_SETPROP = _IOWR(0, 8, struct fsl_hv_ioctl_prop),
> +};

Missing an entry in Documentation/ioctl/ioctl-number.txt for 0 (with conflict!).

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On 06/09/11 12:47, Timur Tabi wrote:
> Randy Dunlap wrote:
>>>> +enum fsl_hv_ioctl_cmd {
>>>> +  FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct 
>>>> fsl_hv_ioctl_restart),
>>>> +  FSL_HV_IOCTL_PARTITION_GET_STATUS = _IOWR(0, 2, struct 
>>>> fsl_hv_ioctl_status),
>>>> +  FSL_HV_IOCTL_PARTITION_START = _IOWR(0, 3, struct fsl_hv_ioctl_start),
>>>> +  FSL_HV_IOCTL_PARTITION_STOP = _IOWR(0, 4, struct fsl_hv_ioctl_stop),
>>>> +  FSL_HV_IOCTL_MEMCPY = _IOWR(0, 5, struct fsl_hv_ioctl_memcpy),
>>>> +  FSL_HV_IOCTL_DOORBELL = _IOWR(0, 6, struct fsl_hv_ioctl_doorbell),
>>>> +  FSL_HV_IOCTL_GETPROP = _IOWR(0, 7, struct fsl_hv_ioctl_prop),
>>>> +  FSL_HV_IOCTL_SETPROP = _IOWR(0, 8, struct fsl_hv_ioctl_prop),
>>>> +};
> 
>> Missing an entry in Documentation/ioctl/ioctl-number.txt for 0 (with 
>> conflict!).
> 
> If I change it from 0, I'm going to break binary compatibility with our apps. 
>  I
> agree that maybe I shouldn't have picked 0, but considering how many conflicts
> there already are, I wonder what the point is.  Even if I pick a number that 
> is
> currently not listed in the chart, that doesn't mean that it's actually not
> being used, or that it won't conflict in the future.

Yes, I understood that.

> So is it okay to stick with 0, or do I need to pick a new number?

I wasn't suggesting that you change the 0, just note that it has conflicts,
like other ioctls do.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFCv1 2/3] fpga: add CARMA DATA-FPGA Access Driver

[Randy Dunlap]

On Fri,  3 Sep 2010 15:30:51 -0700 Ira W. Snyder wrote:

> This driver allows userspace to access the data processing FPGAs on the
> OVRO CARMA board. It has two modes of operation:
> 
> 1) random access
> 
> This allows users to poke any DATA-FPGA registers by using mmap to map
> the address region directly into their memory map.
> 
> 2) correlation dumping
> 
> When correlating, the DATA-FPGA's have special requirements for getting
> the data out of their memory before the next correlation. This nominally
> happens at 64Hz (every 15.625ms). If the data is not dumped before the
> next correlation, data is lost.
> 
> The data dumping driver handles buffering up to 1 second worth of
> correlation data from the FPGAs. This lowers the realtime scheduling
> requirements for the userspace process reading the device.
> 
> Signed-off-by: Ira W. Snyder 
> ---
>  drivers/fpga/carma/Kconfig  |9 +
>  drivers/fpga/carma/Makefile |1 +
>  drivers/fpga/carma/carma-fpga.c | 1447 
> +++
>  3 files changed, 1457 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/fpga/carma/carma-fpga.c
> 
> diff --git a/drivers/fpga/carma/Kconfig b/drivers/fpga/carma/Kconfig
> index 448885e..5592f73 100644
> --- a/drivers/fpga/carma/Kconfig
> +++ b/drivers/fpga/carma/Kconfig
> @@ -18,4 +18,13 @@ config CARMA
> Say Y here to include basic support for the CARMA System Controller
> FPGA. This option allows the other more advanced drivers to be built.
>  
> +config CARMA_FPGA
> + tristate "CARMA DATA-FPGA Access Driver"
> + depends on CARMA
> + select VIDEOBUF_DMA_SG

You can't safely select VIDEOBUF_DMA_SG unless MEDIA_SUPPORT && HAS_DMA are
enabled, so I would add
depends on MEDIA_SUPPORT && HAS_DMA
to this config symbol.


> + default n
> + help
> +   Say Y here to include support for communicating with the data
> +   processing FPGAs on the CARMA board.
> +
>  endif # FPGA_DRIVERS

> diff --git a/drivers/fpga/carma/carma-fpga.c b/drivers/fpga/carma/carma-fpga.c
> new file mode 100644
> index 000..ab1b536
> --- /dev/null
> +++ b/drivers/fpga/carma/carma-fpga.c
> @@ -0,0 +1,1447 @@
> +/*
> + * Free a single data buffer and all allocated pages
> + *
> + * This will free all of the pages allocated to the given data buffer, and
> + * then free the structure itself
> + *
> + * @dev: the DMA device to map for
> + * @buf: the buffer to free
> + */
> +static void data_free_buffer(struct device *dev, struct data_buf *buf)
> +{

The comments above are OK, but please don't add the (doxygen?) style comments
as below (this is just one example of multiple occurrences).
Specifically, the "@param" parts.
It would be better to use the style above (if not using kernel-doc notation).


> +/*
> + * Prepare and submit a DMA_SLAVE transaction for a correlation data buffer
> + *
> + * LOCKING: must hold dev->lock
> + * CONTEXT: hardirq only
> + *
> + * @param priv the driver's private data structure
> + * @param buf the data buffer to DMA into
> + * @return 0 on success, -ERRNO otherwise
> + */
> +static int data_submit_dma(struct fpga_device *priv, struct data_buf *buf)
> +{


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [BUG 2.6.36-rc5] of_i2c.ko <-> i2c-core.ko dependency loop

[Randy Dunlap]

On Thu, 23 Sep 2010 13:53:18 +0200 Mikael Pettersson wrote:

> Running modules_install from a newly built 2.6.36-rc5 kernel
> on my 32-bit PowerMac results in:
> 
> WARNING: Module 
> /lib/modules/2.6.36-rc5/kernel/drivers/i2c/busses/i2c-powermac.ko ignored, 
> due to loop
> WARNING: Loop detected: 
> /lib/modules/2.6.36-rc5/kernel/drivers/i2c/i2c-core.ko needs of_i2c.ko which 
> needs i2c-core.ko again!
> WARNING: Module /lib/modules/2.6.36-rc5/kernel/drivers/i2c/i2c-core.ko 
> ignored, due to loop
> WARNING: Module /lib/modules/2.6.36-rc5/kernel/drivers/i2c/i2c-dev.ko 
> ignored, due to loop
> WARNING: Module /lib/modules/2.6.36-rc5/kernel/drivers/of/of_i2c.ko ignored, 
> due to loop
> WARNING: Module /lib/modules/2.6.36-rc5/kernel/sound/ppc/snd-powermac.ko 
> ignored, due to loop
> 
> > grep '.*I2C.*=' .config
> CONFIG_OF_I2C=m
> CONFIG_I2C=m
> CONFIG_I2C_BOARDINFO=y
> CONFIG_I2C_CHARDEV=m
> CONFIG_I2C_POWERMAC=m
> 
> I can't say exactly when this started, haven't built kernels on this
> box in a while.


No kconfig warnings?  Please post your full .config file.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [BUG 2.6.36-rc5] of_i2c.ko <-> i2c-core.ko dependency loop

[Randy Dunlap]

On Thu, 23 Sep 2010 22:16:32 +0200 Mikael Pettersson wrote:

> Randy Dunlap writes:
>  > On Thu, 23 Sep 2010 13:53:18 +0200 Mikael Pettersson wrote:
>  > 
>  > > Running modules_install from a newly built 2.6.36-rc5 kernel
>  > > on my 32-bit PowerMac results in:
>  > > 
>  > > WARNING: Module 
> /lib/modules/2.6.36-rc5/kernel/drivers/i2c/busses/i2c-powermac.ko ignored, 
> due to loop
>  > > WARNING: Loop detected: 
> /lib/modules/2.6.36-rc5/kernel/drivers/i2c/i2c-core.ko needs of_i2c.ko which 
> needs i2c-core.ko again!
>  > > WARNING: Module /lib/modules/2.6.36-rc5/kernel/drivers/i2c/i2c-core.ko 
> ignored, due to loop
>  > > WARNING: Module /lib/modules/2.6.36-rc5/kernel/drivers/i2c/i2c-dev.ko 
> ignored, due to loop
>  > > WARNING: Module /lib/modules/2.6.36-rc5/kernel/drivers/of/of_i2c.ko 
> ignored, due to loop
>  > > WARNING: Module /lib/modules/2.6.36-rc5/kernel/sound/ppc/snd-powermac.ko 
> ignored, due to loop
>  > > 
>  > > > grep '.*I2C.*=' .config
>  > > CONFIG_OF_I2C=m
>  > > CONFIG_I2C=m
>  > > CONFIG_I2C_BOARDINFO=y
>  > > CONFIG_I2C_CHARDEV=m
>  > > CONFIG_I2C_POWERMAC=m
>  > > 
>  > > I can't say exactly when this started, haven't built kernels on this
>  > > box in a while.
>  > 
>  > 
>  > No kconfig warnings?
> 
> Not that I recall.  I can check tomorrow if necessary.

No kconfig warnings.  I checked with your .config file.

>  > Please post your full .config file.

Just a matter of module i2c-core calls of_ functions and module of_i2c calls
i2c_ functions.  Hmph.  Something for Grant, Jean, and Ben to work out.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers

[Randy Dunlap]

Hi,
just kernel-doc fixes:

On 9/4/19 1:19 PM, Aleksa Sarai wrote:
> 
> diff --git a/lib/struct_user.c b/lib/struct_user.c
> new file mode 100644
> index ..7301ab1bbe98
> --- /dev/null
> +++ b/lib/struct_user.c
> @@ -0,0 +1,182 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2019 SUSE LLC
> + * Copyright (C) 2019 Aleksa Sarai 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define BUFFER_SIZE 64
> +

> +
> +/**
> + * copy_struct_to_user: copy a struct to user space

use correct format:

* copy_struct_to_user - copy a struct to user space

> + * @dst:   Destination address, in user space.
> + * @usize: Size of @dst struct.
> + * @src:   Source address, in kernel space.
> + * @ksize: Size of @src struct.
> + *
> + * Copies a struct from kernel space to user space, in a way that guarantees
> + * backwards-compatibility for struct syscall arguments (as long as future
> + * struct extensions are made such that all new fields are *appended* to the
> + * old struct, and zeroed-out new fields have the same meaning as the old
> + * struct).
> + *
> + * @ksize is just sizeof(*dst), and @usize should've been passed by user 
> space.
> + * The recommended usage is something like the following:
> + *
> + *   SYSCALL_DEFINE2(foobar, struct foo __user *, uarg, size_t, usize)
> + *   {
> + *  int err;
> + *  struct foo karg = {};
> + *
> + *  // do something with karg
> + *
> + *  err = copy_struct_to_user(uarg, usize, &karg, sizeof(karg));
> + *  if (err)
> + *return err;
> + *
> + *  // ...
> + *   }
> + *
> + * There are three cases to consider:
> + *  * If @usize == @ksize, then it's copied verbatim.
> + *  * If @usize < @ksize, then kernel space is "returning" a newer struct to 
> an
> + *older user space. In order to avoid user space getting incomplete
> + *information (new fields might be important), all trailing bytes in @src
> + *(@ksize - @usize) must be zerored, otherwise -EFBIG is returned.
> + *  * If @usize > @ksize, then the kernel is "returning" an older struct to a
> + *newer user space. The trailing bytes in @dst (@usize - @ksize) will be
> + *zero-filled.
> + *
> + * Returns (in all cases, some data may have been copied):
> + *  * -EFBIG:  (@usize < @ksize) and there are non-zero trailing bytes in 
> @src.
> + *  * -EFAULT: access to user space failed.
> + */
> +int copy_struct_to_user(void __user *dst, size_t usize,
> + const void *src, size_t ksize)
> +{
> + size_t size = min(ksize, usize);
> + size_t rest = abs(ksize - usize);
> +
> + if (unlikely(usize > PAGE_SIZE))
> + return -EFAULT;
> + if (unlikely(!access_ok(dst, usize)))
> + return -EFAULT;
> +
> + /* Deal with trailing bytes. */
> + if (usize < ksize) {
> + if (memchr_inv(src + size, 0, rest))
> + return -EFBIG;
> + } else if (usize > ksize) {
> + if (__memzero_user(dst + size, rest))
> + return -EFAULT;
> + }
> + /* Copy the interoperable parts of the struct. */
> + if (__copy_to_user(dst, src, size))
> + return -EFAULT;
> + return 0;
> +}
> +EXPORT_SYMBOL(copy_struct_to_user);
> +
> +/**

same here:

> + * copy_struct_from_user: copy a struct from user space

* copy_struct_from_user - copy a struct from user space

> + * @dst:   Destination address, in kernel space. This buffer must be @ksize
> + * bytes long.
> + * @ksize: Size of @dst struct.
> + * @src:   Source address, in user space.
> + * @usize: (Alleged) size of @src struct.
> + *
> + * Copies a struct from user space to kernel space, in a way that guarantees
> + * backwards-compatibility for struct syscall arguments (as long as future
> + * struct extensions are made such that all new fields are *appended* to the
> + * old struct, and zeroed-out new fields have the same meaning as the old
> + * struct).
> + *
> + * @ksize is just sizeof(*dst), and @usize should've been passed by user 
> space.
> + * The recommended usage is something like the following:
> + *
> + *   SYSCALL_DEFINE2(foobar, const struct foo __user *, uarg, size_t, usize)
> + *   {
> + *  int err;
> + *  struct foo karg = {};
> + *
> + *  err = copy_struct_from_user(&karg, sizeof(karg), uarg, size);
> + *  if (err)
> + *return err;
> + *
> + *  // ...
> + *   }
> + *
> + * There are three cases to consider:
> + *  * If @usize == @ksize, then it's copied verbatim.
> + *  * If @usize < @ksize, then the user space has passed an old struct to a
> + *newer kernel. The rest of the trailing bytes in @dst (@ksize - @usize)
> + *are to be zero-filled.
> + *  * If @usize > @ksize, then the user space has passed a new struct to an
> + *older kernel. The trailing bytes unknown to the kernel (@usize - 
> @ksize)
> + *are checked to ensure they are zeroed, otherwise -E2BIG is returne

Re: [PATCH v12 11/12] open: openat2(2) syscall

[Randy Dunlap]

Hi,
just noisy nits here:

On 9/4/19 1:19 PM, Aleksa Sarai wrote:

> diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
> index 1d338357df8a..479baf2da10e 100644
> --- a/include/uapi/linux/fcntl.h
> +++ b/include/uapi/linux/fcntl.h
> @@ -93,5 +93,47 @@
>  
>  #define AT_RECURSIVE 0x8000  /* Apply to the entire subtree */
>  
> +/**

/** means "the following is kernel-doc", but it's not, so please either make
it kernel-doc format or just use /* to begin the comment.

> + * Arguments for how openat2(2) should open the target path. If @resolve is
> + * zero, then openat2(2) operates identically to openat(2).
> + *
> + * However, unlike openat(2), unknown bits in @flags result in -EINVAL rather
> + * than being silently ignored. In addition, @mode (or @upgrade_mask) must be
> + * zero unless one of {O_CREAT, O_TMPFILE, O_PATH} are set.
> + *
> + * @flags: O_* flags.
> + * @mode: O_CREAT/O_TMPFILE file mode.
> + * @upgrade_mask: UPGRADE_* flags (to restrict O_PATH re-opening).
> + * @resolve: RESOLVE_* flags.
> + */
> +struct open_how {
> + __u32 flags;
> + union {
> + __u16 mode;
> + __u16 upgrade_mask;
> + };
> + __u16 resolve;
> +};


-- 
~Randy

Re: [PATCH] powerpc/82xx: Select FSL_SOC

[Randy Dunlap]

On 9/14/23 08:23, Christophe Leroy wrote:
> It used to be impossible to select CONFIG_CPM2 without selecting
> CONFIG_FSL_SOC at the same time because CONFIG_CPM2 was dependent
> on CONFIG_8260 and CONFIG_8260 was selecting CONFIG_FSL_SOC.
> 
> But after commit eb5aa2137275 ("powerpc/82xx: Remove CONFIG_8260
> and CONFIG_8272") CONFIG_CPM2 depends on CONFIG_MPC82xx instead
> but CONFIG_MPC82xx doesn't directly selects CONFIG_FSL_SOC.
> 
> Fix it by forcing CONFIG_MPC82xx to select CONFIG_FSL_SOC just
> like already done by MPC8xx, MPC512x, MPC83xx, PPC_86xx.
> 
> Reported-by: Randy Dunlap 
> Fixes: eb5aa2137275 ("powerpc/82xx: Remove CONFIG_8260 and CONFIG_8272")
> Signed-off-by: Christophe Leroy 

Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 

Thanks for tracking this down.

> ---
>  arch/powerpc/platforms/82xx/Kconfig | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/82xx/Kconfig 
> b/arch/powerpc/platforms/82xx/Kconfig
> index d9f1a2a83158..1824536cf6f2 100644
> --- a/arch/powerpc/platforms/82xx/Kconfig
> +++ b/arch/powerpc/platforms/82xx/Kconfig
> @@ -2,6 +2,7 @@
>  menuconfig PPC_82xx
>   bool "82xx-based boards (PQ II)"
>   depends on PPC_BOOK3S_32
> + select FSL_SOC
>  
>  if PPC_82xx
>  
> @@ -9,7 +10,6 @@ config EP8248E
>   bool "Embedded Planet EP8248E (a.k.a. CWH-PPC-8248N-VE)"
>   select CPM2
>   select PPC_INDIRECT_PCI if PCI
> - select FSL_SOC
>   select PHYLIB if NETDEVICES
>   select MDIO_BITBANG if PHYLIB
>   help
> @@ -22,7 +22,6 @@ config MGCOGE
>   bool "Keymile MGCOGE"
>   select CPM2
>   select PPC_INDIRECT_PCI if PCI
> - select FSL_SOC
>   help
> This enables support for the Keymile MGCOGE board.
>  

-- 
~Randy

Re: linux-next: Tree for Sep 20 (ppc32: ADB_CUDA Kconfig warning)

[Randy Dunlap]

On 9/19/23 20:37, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20230919:
> 
> The mm tree lost its boot warning.
> 
> The drm-misc tree gained a conflict against Linus' tree.
> 
> Non-merge commits (relative to Linus' tree): 6006
>  3996 files changed, 459968 insertions(+), 111742 deletions(-)
> 
> 

4 out of 10 randconfigs have this warning:

WARNING: unmet direct dependencies detected for ADB_CUDA
  Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) && 
!PPC_PMAC64 [=n]
  Selected by [y]:
  - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET [=y] 
&& PPC32 [=y]

WARNING: unmet direct dependencies detected for ADB_CUDA
  Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) && 
!PPC_PMAC64 [=n]
  Selected by [y]:
  - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET [=y] 
&& PPC32 [=y]

WARNING: unmet direct dependencies detected for ADB_CUDA
  Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) && 
!PPC_PMAC64 [=n]
  Selected by [y]:
  - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET [=y] 
&& PPC32 [=y]


One failing randconfig file is attached.
-- 
~Randy

config-r7483.gz
Description: application/gzip

Re: linux-next: Tree for Sep 20 (ppc32: ADB_CUDA Kconfig warning)

[Randy Dunlap]

On 9/21/23 17:10, Michael Ellerman wrote:
> Randy Dunlap  writes:
>> On 9/19/23 20:37, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20230919:
>>>
>>> The mm tree lost its boot warning.
>>>
>>> The drm-misc tree gained a conflict against Linus' tree.
>>>
>>> Non-merge commits (relative to Linus' tree): 6006
>>>  3996 files changed, 459968 insertions(+), 111742 deletions(-)
>>>
>>> 
>>
>> 4 out of 10 randconfigs have this warning:
>>
>> WARNING: unmet direct dependencies detected for ADB_CUDA
>>   Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) && 
>> !PPC_PMAC64 [=n]
>>   Selected by [y]:
>>   - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET 
>> [=y] && PPC32 [=y]
>>
>> WARNING: unmet direct dependencies detected for ADB_CUDA
>>   Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) && 
>> !PPC_PMAC64 [=n]
>>   Selected by [y]:
>>   - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET 
>> [=y] && PPC32 [=y]
>>
>> WARNING: unmet direct dependencies detected for ADB_CUDA
>>   Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) && 
>> !PPC_PMAC64 [=n]
>>   Selected by [y]:
>>   - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET 
>> [=y] && PPC32 [=y]
> 
> Crud. Caused by:
> 
> a3ef2fef198c ("powerpc/32: Add dependencies of POWER_RESET for pmac32")
> 
> I was suspicious of that select, I should have been *more* suspicious :)
> 
> I think this is a fix. The PPC32 isn't needed because ADB depends on 
> (PPC_PMAC && PPC32).

Yes, that fixes the problem. Thanks.

Tested-by: Randy Dunlap 
Acked-by: Randy Dunlap 

> 
> diff --git a/arch/powerpc/platforms/powermac/Kconfig 
> b/arch/powerpc/platforms/powermac/Kconfig
> index 8bdae0caf21e..84f101ec53a9 100644
> --- a/arch/powerpc/platforms/powermac/Kconfig
> +++ b/arch/powerpc/platforms/powermac/Kconfig
> @@ -2,7 +2,7 @@
>  config PPC_PMAC
> bool "Apple PowerMac based machines"
> depends on PPC_BOOK3S && CPU_BIG_ENDIAN
> -   select ADB_CUDA if POWER_RESET && PPC32
> +   select ADB_CUDA if POWER_RESET && ADB
> select MPIC
> select FORCE_PCI
> select PPC_INDIRECT_PCI if PPC32
> 
> cheers

-- 
~Randy

Re: linux-next: Tree for Sep 26 (arch/powerpc/platforms/86xx/pic.o)

[Randy Dunlap]

On 9/25/23 22:50, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20230925:
> 

on powerpc 32BIT:

powerpc-linux-ld: arch/powerpc/platforms/86xx/pic.o: in function 
`mpc86xx_init_irq':
pic.c:(.init.text+0x38): undefined reference to `mpic_alloc'
powerpc-linux-ld: pic.c:(.init.text+0x58): undefined reference to `mpic_init'


Full randconfig file is attached.

-- 
~Randy

config-r7757.gz
Description: application/gzip

[PATCH] soc: fsl: dpio: fix kernel-doc typos

[Randy Dunlap]

Correct spelling of 2 words.

Signed-off-by: Randy Dunlap 
Cc: Li Yang 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: Roy Pledge 
---
 include/soc/fsl/dpaa2-io.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -- a/include/soc/fsl/dpaa2-io.h b/include/soc/fsl/dpaa2-io.h
--- a/include/soc/fsl/dpaa2-io.h
+++ b/include/soc/fsl/dpaa2-io.h
@@ -22,7 +22,7 @@ struct device;
  * DOC: DPIO Service
  *
  * The DPIO service provides APIs for users to interact with the datapath
- * by enqueueing and dequeing frame descriptors.
+ * by enqueueing and dequeueing frame descriptors.
  *
  * The following set of APIs can be used to enqueue and dequeue frames
  * as well as producing notification callbacks when data is available
@@ -33,7 +33,7 @@ struct device;
 
 /**
  * struct dpaa2_io_desc - The DPIO descriptor
- * @receives_notifications: Use notificaton mode. Non-zero if the DPIO
+ * @receives_notifications: Use notification mode. Non-zero if the DPIO
  *  has a channel.
  * @has_8prio:  Set to non-zero for channel with 8 priority WQs.  Ignored
  *  unless receives_notification is TRUE.

[PATCH] soc: fsl: fix kernel-doc warnings and typos

[Randy Dunlap]

Correct spelling of "list".

Fix a kernel-doc warning by describing the nested structure completely:

include/soc/fsl/dpaa2-fd.h:52: warning: Function parameter or member 'simple' 
not described in 'dpaa2_fd'

Signed-off-by: Randy Dunlap 
Cc: Li Yang 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
 include/soc/fsl/dpaa2-fd.h |   19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff -- a/include/soc/fsl/dpaa2-fd.h b/include/soc/fsl/dpaa2-fd.h
--- a/include/soc/fsl/dpaa2-fd.h
+++ b/include/soc/fsl/dpaa2-fd.h
@@ -25,14 +25,15 @@
 
 /**
  * struct dpaa2_fd - Struct describing FDs
- * @words: for easier/faster copying the whole FD structure
- * @addr:  address in the FD
- * @len:   length in the FD
- * @bpid:  buffer pool ID
- * @format_offset: format, offset, and short-length fields
- * @frc:   frame context
- * @ctrl:  control bits...including dd, sc, va, err, etc
- * @flc:   flow context address
+ * @words:for easier/faster copying the whole FD structure
+ * @simple:   struct for the FD fields
+ * @simple.addr:  address in the FD
+ * @simple.len:   length in the FD
+ * @simple.bpid:  buffer pool ID
+ * @simple.format_offset: format, offset, and short-length fields
+ * @simple.frc:   frame context
+ * @simple.ctrl:  control bits...including dd, sc, va, err, etc
+ * @simple.flc:   flow context address
  *
  * This structure represents the basic Frame Descriptor used in the system.
  */
@@ -497,7 +498,7 @@ static inline void dpaa2_fl_set_addr(str
  * dpaa2_fl_get_frc() - Get the frame context in the FLE
  * @fle: the given frame list entry
  *
- * Return the frame context field in the frame lsit entry.
+ * Return the frame context field in the frame list entry.
  */
 static inline u32 dpaa2_fl_get_frc(const struct dpaa2_fl_entry *fle)
 {

Re: linux-next: Tree for Sep 20 (ppc32: ADB_CUDA Kconfig warning)

[Randy Dunlap]

Hi Michael,

On 9/21/23 21:51, Randy Dunlap wrote:
> 
> 
> On 9/21/23 17:10, Michael Ellerman wrote:
>> Randy Dunlap  writes:
>>> On 9/19/23 20:37, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Changes since 20230919:
>>>>
>>>> The mm tree lost its boot warning.
>>>>
>>>> The drm-misc tree gained a conflict against Linus' tree.
>>>>
>>>> Non-merge commits (relative to Linus' tree): 6006
>>>>  3996 files changed, 459968 insertions(+), 111742 deletions(-)
>>>>
>>>> 
>>>
>>> 4 out of 10 randconfigs have this warning:
>>>
>>> WARNING: unmet direct dependencies detected for ADB_CUDA
>>>   Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) && 
>>> !PPC_PMAC64 [=n]
>>>   Selected by [y]:
>>>   - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET 
>>> [=y] && PPC32 [=y]
>>>
>>> WARNING: unmet direct dependencies detected for ADB_CUDA
>>>   Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) && 
>>> !PPC_PMAC64 [=n]
>>>   Selected by [y]:
>>>   - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET 
>>> [=y] && PPC32 [=y]
>>>
>>> WARNING: unmet direct dependencies detected for ADB_CUDA
>>>   Depends on [n]: MACINTOSH_DRIVERS [=n] && (ADB [=n] || PPC_PMAC [=y]) && 
>>> !PPC_PMAC64 [=n]
>>>   Selected by [y]:
>>>   - PPC_PMAC [=y] && PPC_BOOK3S [=y] && CPU_BIG_ENDIAN [=y] && POWER_RESET 
>>> [=y] && PPC32 [=y]
>>
>> Crud. Caused by:
>>
>> a3ef2fef198c ("powerpc/32: Add dependencies of POWER_RESET for pmac32")
>>
>> I was suspicious of that select, I should have been *more* suspicious :)
>>
>> I think this is a fix. The PPC32 isn't needed because ADB depends on 
>> (PPC_PMAC && PPC32).
> 
> Yes, that fixes the problem. Thanks.
> 
> Tested-by: Randy Dunlap 
> Acked-by: Randy Dunlap 
> 

Will you be merging this fix?

Thanks.

>>
>> diff --git a/arch/powerpc/platforms/powermac/Kconfig 
>> b/arch/powerpc/platforms/powermac/Kconfig
>> index 8bdae0caf21e..84f101ec53a9 100644
>> --- a/arch/powerpc/platforms/powermac/Kconfig
>> +++ b/arch/powerpc/platforms/powermac/Kconfig
>> @@ -2,7 +2,7 @@
>>  config PPC_PMAC
>> bool "Apple PowerMac based machines"
>> depends on PPC_BOOK3S && CPU_BIG_ENDIAN
>> -   select ADB_CUDA if POWER_RESET && PPC32
>> +   select ADB_CUDA if POWER_RESET && ADB
>> select MPIC
>> select FORCE_PCI
>> select PPC_INDIRECT_PCI if PPC32
>>
>> cheers
> 

-- 
~Randy

Re: linux-next: Tree for Nov 16 (arch/powerpc/platforms/86xx/pic.o)

[Randy Dunlap]

On 11/15/23 18:17, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20231115:
> 

on ppc32 (using gcc 13.2.0 from kernel.org):


CONFIG_PPC_86xx=y
# CONFIG_GEF_PPC9A is not set
# CONFIG_GEF_SBC310 is not set
# CONFIG_GEF_SBC610 is not set
# CONFIG_MVME7100 is not set

(CONFIG_MPIC is not set)


powerpc-linux-ld: arch/powerpc/platforms/86xx/pic.o: in function 
`mpc86xx_init_irq':
pic.c:(.init.text+0x30): undefined reference to `mpic_alloc'
powerpc-linux-ld: pic.c:(.init.text+0x44): undefined reference to `mpic_init'

Full randconfig file is attached.

-- 
~Randy

config-r2005.gz
Description: application/gzip

Re: [PATCH] syscalls: Cleanup references to sys_lookup_dcookie()

[Randy Dunlap]

On 6/28/23 16:09, Sohil Mehta wrote:
> commit 'be65de6b03aa ("fs: Remove dcookies support")' removed the
> syscall definition for lookup_dcookie.  However, syscall tables still
> point to the old sys_lookup_dcookie() definition. Update syscall tables
> of all architectures to directly point to sys_ni_syscall() instead.
> 
> Signed-off-by: Sohil Mehta 

Reviewed-by: Randy Dunlap 

Thanks.

> ---
> This patch has a dependency on another patch that has been applied to the
> asm-generic tree:
> https://lore.kernel.org/lkml/20230621223600.1348693-1-sohil.me...@intel.com/
> ---
>  arch/alpha/kernel/syscalls/syscall.tbl  | 2 +-
>  arch/arm/tools/syscall.tbl  | 2 +-
>  arch/arm64/include/asm/unistd32.h   | 4 ++--
>  arch/ia64/kernel/syscalls/syscall.tbl   | 2 +-
>  arch/m68k/kernel/syscalls/syscall.tbl   | 2 +-
>  arch/microblaze/kernel/syscalls/syscall.tbl | 2 +-
>  arch/mips/kernel/syscalls/syscall_n32.tbl   | 2 +-
>  arch/mips/kernel/syscalls/syscall_n64.tbl   | 2 +-
>  arch/mips/kernel/syscalls/syscall_o32.tbl   | 2 +-
>  arch/parisc/kernel/syscalls/syscall.tbl | 2 +-
>  arch/powerpc/kernel/syscalls/syscall.tbl| 2 +-
>  arch/s390/kernel/syscalls/syscall.tbl   | 2 +-
>  arch/sh/kernel/syscalls/syscall.tbl | 2 +-
>  arch/sparc/kernel/syscalls/syscall.tbl  | 2 +-
>  arch/x86/entry/syscalls/syscall_32.tbl  | 2 +-
>  arch/x86/entry/syscalls/syscall_64.tbl  | 2 +-
>  arch/xtensa/kernel/syscalls/syscall.tbl | 2 +-
>  include/linux/compat.h  | 1 -
>  include/linux/syscalls.h| 1 -
>  include/uapi/asm-generic/unistd.h   | 2 +-
>  kernel/sys_ni.c | 2 --
>  tools/include/uapi/asm-generic/unistd.h | 2 +-
>  tools/perf/arch/mips/entry/syscalls/syscall_n64.tbl | 2 +-
>  tools/perf/arch/powerpc/entry/syscalls/syscall.tbl  | 2 +-
>  tools/perf/arch/s390/entry/syscalls/syscall.tbl | 2 +-
>  tools/perf/arch/x86/entry/syscalls/syscall_64.tbl   | 2 +-
>  26 files changed, 24 insertions(+), 28 deletions(-)
> 


-- 
~Randy

Re: [PATCH] powerpc: Include asm/nmi.c in mobility.c for watchdog_hardlockup_set_timeout_pct()

[Randy Dunlap]

On 6/29/23 12:45, Douglas Anderson wrote:
> The powerpc/platforms/pseries/mobility.c calls
> watchdog_hardlockup_set_timeout_pct(), which is declared in
> . We used to automatically get  included, but
> that changed as of commit 7ca8fe94aa92 ("watchdog/hardlockup: define
> HARDLOCKUP_DETECTOR_ARCH"). Let's add the explicit include.
> 
> Reported-by: Randy Dunlap 
> Closes: 
> https://lore.kernel.org/r/af19b76d-aa4b-6c88-9cac-eae4b2072...@infradead.org
> Fixes: 7ca8fe94aa92 ("watchdog/hardlockup: define HARDLOCKUP_DETECTOR_ARCH")
> Signed-off-by: Douglas Anderson 

Reviewed-by: Randy Dunlap 
Tested-by: Randy Dunlap  # build-tested

Thanks.

> ---
> 
>  arch/powerpc/platforms/pseries/mobility.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/powerpc/platforms/pseries/mobility.c 
> b/arch/powerpc/platforms/pseries/mobility.c
> index cd632ba9ebff..0161226d8fec 100644
> --- a/arch/powerpc/platforms/pseries/mobility.c
> +++ b/arch/powerpc/platforms/pseries/mobility.c
> @@ -24,6 +24,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include "pseries.h"
>  #include "vas.h" /* vas_migration_handler() */

-- 
~Randy

[PATCH v2 RESEND RESEND] ASoC: fsl MPC52xx drivers require PPC_BESTCOMM

[Randy Dunlap]

Both SND_MPC52xx_SOC_PCM030 and SND_MPC52xx_SOC_EFIKA select
SND_SOC_MPC5200_AC97. The latter symbol depends on PPC_BESTCOMM,
so the 2 former symbols should also depend on PPC_BESTCOMM since
"select" does not follow any dependency chains.

This prevents a kconfig warning and build errors:

WARNING: unmet direct dependencies detected for SND_SOC_MPC5200_AC97
  Depends on [n]: SOUND [=y] && !UML && SND [=m] && SND_SOC [=m] && 
SND_POWERPC_SOC [=m] && PPC_MPC52xx [=y] && PPC_BESTCOMM [=n]
  Selected by [m]:
  - SND_MPC52xx_SOC_PCM030 [=m] && SOUND [=y] && !UML && SND [=m] && SND_SOC 
[=m] && SND_POWERPC_SOC [=m] && PPC_MPC5200_SIMPLE [=y]
  - SND_MPC52xx_SOC_EFIKA [=m] && SOUND [=y] && !UML && SND [=m] && SND_SOC 
[=m] && SND_POWERPC_SOC [=m] && PPC_EFIKA [=y]

ERROR: modpost: "mpc5200_audio_dma_destroy" [sound/soc/fsl/mpc5200_psc_ac97.ko] 
undefined!
ERROR: modpost: "mpc5200_audio_dma_create" [sound/soc/fsl/mpc5200_psc_ac97.ko] 
undefined!

Fixes: 40d9ec14e7e1 ("ASoC: remove BROKEN from Efika and pcm030 fabric drivers")
Signed-off-by: Randy Dunlap 
Cc: Grant Likely 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Shengjiu Wang 
Cc: Xiubo Li 
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Acked-by: Shengjiu Wang 
---
v2: use correct email address for Mark Brown.

 sound/soc/fsl/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -- a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -243,7 +243,7 @@ config SND_SOC_MPC5200_AC97
 
 config SND_MPC52xx_SOC_PCM030
tristate "SoC AC97 Audio support for Phytec pcm030 and WM9712"
-   depends on PPC_MPC5200_SIMPLE
+   depends on PPC_MPC5200_SIMPLE && PPC_BESTCOMM
select SND_SOC_MPC5200_AC97
select SND_SOC_WM9712
help
@@ -252,7 +252,7 @@ config SND_MPC52xx_SOC_PCM030
 
 config SND_MPC52xx_SOC_EFIKA
tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
-   depends on PPC_EFIKA
+   depends on PPC_EFIKA && PPC_BESTCOMM
select SND_SOC_MPC5200_AC97
select SND_SOC_STAC9766
help

Re: [PATCH] powerpc: allow PPC_EARLY_DEBUG_CPM only when SERIAL_CPM=y

[Randy Dunlap]

On 6/9/23 20:11, Randy Dunlap wrote:
> Hi--
> 
> On 5/16/23 11:54, Pali Rohár wrote:
>> On Tuesday 16 May 2023 08:28:54 Randy Dunlap wrote:
>>> In a randconfig with CONFIG_SERIAL_CPM=m and
>>> CONFIG_PPC_EARLY_DEBUG_CPM=y, there is a build error:
>>> ERROR: modpost: "udbg_putc" [drivers/tty/serial/cpm_uart/cpm_uart.ko] 
>>> undefined!
>>>
>>> Prevent the build error by allowing PPC_EARLY_DEBUG_CPM only when
>>> SERIAL_CPM=y.
>>>
>>> Fixes: c374e00e17f1 ("[POWERPC] Add early debug console for CPM serial 
>>> ports.")
>>> Signed-off-by: Randy Dunlap 
>>> Cc: Scott Wood 
>>> Cc: Kumar Gala 
>>> Cc: "Pali Rohár" 
>>> Cc: Michael Ellerman 
>>> Cc: Nicholas Piggin 
>>> Cc: Christophe Leroy 
>>> Cc: linuxppc-dev@lists.ozlabs.org
>>
>> Looks good,
>>
>> Reviewed-by: Pali Rohár 
> 
> I'm still seeing this build error in linux-next even with other (PPC) CPM
> patches applied.
> 

Patchwork shows status as Superseded:

http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20230516152854.22465-1-rdun...@infradead.org/

but I don't understand why or by what.

I'm going to resubmit the patch now.


>>
>>> ---
>>>  arch/powerpc/Kconfig.debug |2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff -- a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
>>> --- a/arch/powerpc/Kconfig.debug
>>> +++ b/arch/powerpc/Kconfig.debug
>>> @@ -240,7 +240,7 @@ config PPC_EARLY_DEBUG_40x
>>>  
>>>  config PPC_EARLY_DEBUG_CPM
>>> bool "Early serial debugging for Freescale CPM-based serial ports"
>>> -   depends on SERIAL_CPM
>>> +   depends on SERIAL_CPM=y
>>> help
>>>   Select this to enable early debugging for Freescale chips
>>>   using a CPM-based serial port.  This assumes that the bootwrapper
> 

-- 
~Randy

[PATCH v2] powerpc: allow PPC_EARLY_DEBUG_CPM only when SERIAL_CPM=y

[Randy Dunlap]

In a randconfig with CONFIG_SERIAL_CPM=m and
CONFIG_PPC_EARLY_DEBUG_CPM=y, there is a build error:
ERROR: modpost: "udbg_putc" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined!

Prevent the build error by allowing PPC_EARLY_DEBUG_CPM only when
SERIAL_CPM=y.

Fixes: c374e00e17f1 ("[POWERPC] Add early debug console for CPM serial ports.")
Signed-off-by: Randy Dunlap 
Cc: Kumar Gala 
Cc: "Pali Rohár" 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: linuxppc-dev@lists.ozlabs.org
Reviewed-by: Pali Rohár 
---
v2: add Pali's R-b;
drop Scott Wood from Cc: list

 arch/powerpc/Kconfig.debug |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -- a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -240,7 +240,7 @@ config PPC_EARLY_DEBUG_40x
 
 config PPC_EARLY_DEBUG_CPM
bool "Early serial debugging for Freescale CPM-based serial ports"
-   depends on SERIAL_CPM
+   depends on SERIAL_CPM=y
help
  Select this to enable early debugging for Freescale chips
  using a CPM-based serial port.  This assumes that the bootwrapper

Re: [PATCH v2 02/10] docs: ABI: sysfs-bus-event_source-devices-hv_gpci: Document processor_bus_topology sysfs interface file

[Randy Dunlap]

Hi--

On 7/10/23 02:27, Kajol Jain wrote:
> Add details of the new hv-gpci interface file called
> "processor_bus_topology" in the ABI documentation.
> 
> Signed-off-by: Kajol Jain 
> ---
>  .../sysfs-bus-event_source-devices-hv_gpci| 32 +++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci 
> b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> index 12e2bf92783f..2eeeab9a20fa 100644
> --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> @@ -80,3 +80,35 @@ Contact:   Linux on PowerPC Developer List 
> 
>  Description: read only
>   This sysfs file exposes the cpumask which is designated to make
>   HCALLs to retrieve hv-gpci pmu event counter data.
> +
> +What:/sys/devices/hv_gpci/interface/processor_bus_topology
> +Date:July 2023
> +Contact: Linux on PowerPC Developer List 
> +Description: admin read only
> + This sysfs file exposes the system topology information by 
> making HCALL
> + H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request 
> value
> + PROCESSOR_BUS_TOPOLOGY(0xD0).
> +
> + * This sysfs file will be created only for power10 and above 
> platforms.
> +
> + * User needs root privileges to read data from this sysfs file.
> +
> + * This sysfs file will be created, only when the HCALL returns 
> "H_SUCESS",


H_SUCCESS

> +   "H_AUTHORITY" and "H_PARAMETER" as the return type.

s/and/or/

> +
> +   HCALL with return error type "H_AUTHORITY", can be resolved 
> during

 Drop the comma ^

> +   runtime by setting "Enable Performance Information 
> Collection" option.
> +
> + * The end user reading this sysfs file must decode the content 
> as per
> +   underlying platform/firmware.
> +
> + Possible error codes while reading this sysfs file:
> +
> + * "-EPERM" : Partition is not permitted to retrieve performance 
> information,
> + required to set "Enable Performance Information 
> Collection" option.
> +
> + * "-EIO" : Can't retrieve system information because of invalid 
> buffer length/invalid address
> +or because of some hardware error. Refer 
> getPerfCountInfo documentation for

  Refer to

> +more information.
> +
> + * "-EFBIG" : System information exceeds PAGE_SIZE.

-- 
~Randy

Re: [PATCH v2 04/10] docs: ABI: sysfs-bus-event_source-devices-hv_gpci: Document processor_config sysfs interface file

[Randy Dunlap]

Hi--

On 7/10/23 02:27, Kajol Jain wrote:
> Add details of the new hv-gpci interface file called
> "processor_config" in the ABI documentation.
> 
> Signed-off-by: Kajol Jain 
> ---
>  .../sysfs-bus-event_source-devices-hv_gpci| 32 +++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci 
> b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> index 2eeeab9a20fa..aff52dc3b05c 100644
> --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> @@ -112,3 +112,35 @@ Description: admin read only
>  more information.
>  
>   * "-EFBIG" : System information exceeds PAGE_SIZE.
> +
> +What:/sys/devices/hv_gpci/interface/processor_config
> +Date:July 2023
> +Contact: Linux on PowerPC Developer List 
> +Description: admin read only
> + This sysfs file exposes the system topology information by 
> making HCALL
> + H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request 
> value
> + PROCESSOR_CONFIG(0x90).
> +
> + * This sysfs file will be created only for power10 and above 
> platforms.
> +
> + * User needs root privileges to read data from this sysfs file.
> +
> + * This sysfs file will be created, only when the HCALL returns 
> "H_SUCESS",


H_SUCCESS

> +   "H_AUTHORITY" and "H_PARAMETER" as the return type.

   s/and/or/

> +
> +   HCALL with return error type "H_AUTHORITY", can be resolved 
> during

  Drop the comma:   ^

> +   runtime by setting "Enable Performance Information 
> Collection" option.
> +
> + * The end user reading this sysfs file must decode the content 
> as per
> +   underlying platform/firmware.
> +
> + Possible error codes while reading this sysfs file:
> +
> + * "-EPERM" : Partition is not permitted to retrieve performance 
> information,
> + required to set "Enable Performance Information 
> Collection" option.
> +
> + * "-EIO" : Can't retrieve system information because of invalid 
> buffer length/invalid address
> +or because of some hardware error. Refer 
> getPerfCountInfo documentation for

  Refer to

> +more information.
> +
> + * "-EFBIG" : System information exceeds PAGE_SIZE.

-- 
~Randy

Re: [PATCH v2 06/10] docs: ABI: sysfs-bus-event_source-devices-hv_gpci: Document affinity_domain_via_virtual_processor sysfs interface file

[Randy Dunlap]

Hi--

On 7/10/23 02:27, Kajol Jain wrote:
> Add details of the new hv-gpci interface file called
> "affinity_domain_via_virtual_processor" in the ABI documentation.
> 
> Signed-off-by: Kajol Jain 
> ---
>  .../sysfs-bus-event_source-devices-hv_gpci| 32 +++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci 
> b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> index aff52dc3b05c..3b63d66658fe 100644
> --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> @@ -144,3 +144,35 @@ Description: admin read only
>  more information.
>  
>   * "-EFBIG" : System information exceeds PAGE_SIZE.
> +
> +What:
> /sys/devices/hv_gpci/interface/affinity_domain_via_virtual_processor
> +Date:July 2023
> +Contact: Linux on PowerPC Developer List 
> +Description: admin read only
> + This sysfs file exposes the system topology information by 
> making HCALL
> + H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request 
> value
> + AFFINITY_DOMAIN_INFORMATION_BY_VIRTUAL_PROCESSOR(0xA0).
> +
> + * This sysfs file will be created only for power10 and above 
> platforms.
> +
> + * User needs root privileges to read data from this sysfs file.
> +
> + * This sysfs file will be created, only when the HCALL returns 
> "H_SUCESS",


H_SUCCESS

> +   "H_AUTHORITY" and "H_PARAMETER" as the return type.

s/and/or/

> +
> +   HCALL with return error type "H_AUTHORITY", can be resolved 
> during

Drop the comma: ^

> +   runtime by setting "Enable Performance Information 
> Collection" option.
> +
> + * The end user reading this sysfs file must decode the content 
> as per
> +   underlying platform/firmware.
> +
> + Possible error codes while reading this sysfs file:
> +
> + * "-EPERM" : Partition is not permitted to retrieve performance 
> information,
> + required to set "Enable Performance Information 
> Collection" option.
> +
> + * "-EIO" : Can't retrieve system information because of invalid 
> buffer length/invalid address
> +or because of some hardware error. Refer 
> getPerfCountInfo documentation for

  Refer to

> +more information.
> +
> + * "-EFBIG" : System information exceeds PAGE_SIZE.

-- 
~Randy

Re: [PATCH v2 08/10] docs: ABI: sysfs-bus-event_source-devices-hv_gpci: Document affinity_domain_via_domain sysfs interface file

[Randy Dunlap]

Hi,

On 7/10/23 02:27, Kajol Jain wrote:
> Add details of the new hv-gpci interface file called
> "affinity_domain_via_domain" in the ABI documentation.
> 
> Signed-off-by: Kajol Jain 
> ---
>  .../sysfs-bus-event_source-devices-hv_gpci| 32 +++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci 
> b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> index 3b63d66658fe..d8e65b93d1f7 100644
> --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> @@ -176,3 +176,35 @@ Description: admin read only
>  more information.
>  
>   * "-EFBIG" : System information exceeds PAGE_SIZE.
> +
> +What:
> /sys/devices/hv_gpci/interface/affinity_domain_via_domain
> +Date:July 2023
> +Contact: Linux on PowerPC Developer List 
> +Description: admin read only
> + This sysfs file exposes the system topology information by 
> making HCALL
> + H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request 
> value
> + AFFINITY_DOMAIN_INFORMATION_BY_DOMAIN(0xB0).
> +
> + * This sysfs file will be created only for power10 and above 
> platforms.
> +
> + * User needs root privileges to read data from this sysfs file.
> +
> + * This sysfs file will be created, only when the HCALL returns 
> "H_SUCESS",


typo

> +   "H_AUTHORITY" and "H_PARAMETER" as the return type.

  s/and/or/

> +
> +   HCALL with return error type "H_AUTHORITY", can be resolved 
> during

Drop the comma: ^

> +   runtime by setting "Enable Performance Information 
> Collection" option.
> +
> + * The end user reading this sysfs file must decode the content 
> as per
> +   underlying platform/firmware.
> +
> + Possible error codes while reading this sysfs file:
> +
> + * "-EPERM" : Partition is not permitted to retrieve performance 
> information,
> + required to set "Enable Performance Information 
> Collection" option.
> +
> + * "-EIO" : Can't retrieve system information because of invalid 
> buffer length/invalid address
> +or because of some hardware error. Refer 
> getPerfCountInfo documentation for

  Refer to

> +more information.
> +
> + * "-EFBIG" : System information exceeds PAGE_SIZE.

-- 
~Randy

Re: [PATCH v2 10/10] docs: ABI: sysfs-bus-event_source-devices-hv_gpci: Document affinity_domain_via_partition sysfs interface file

[Randy Dunlap]

Hi,

Same correction comments as in the other 4 patches (not repeated here).


On 7/10/23 02:27, Kajol Jain wrote:
> Add details of the new hv-gpci interface file called
> "affinity_domain_via_partition" in the ABI documentation.
> 
> Signed-off-by: Kajol Jain 
> ---
>  .../sysfs-bus-event_source-devices-hv_gpci| 32 +++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci 
> b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> index d8e65b93d1f7..b03b2bd4b081 100644
> --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
> @@ -208,3 +208,35 @@ Description: admin read only
>  more information.
>  
>   * "-EFBIG" : System information exceeds PAGE_SIZE.
> +
> +What:
> /sys/devices/hv_gpci/interface/affinity_domain_via_partition
> +Date:July 2023
> +Contact: Linux on PowerPC Developer List 
> +Description: admin read only
> + This sysfs file exposes the system topology information by 
> making HCALL
> + H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request 
> value
> + AFFINITY_DOMAIN_INFORMATION_BY_PARTITION(0xB1).
> +
> + * This sysfs file will be created only for power10 and above 
> platforms.
> +
> + * User needs root privileges to read data from this sysfs file.
> +
> + * This sysfs file will be created, only when the HCALL returns 
> "H_SUCESS",
> +   "H_AUTHORITY" and "H_PARAMETER" as the return type.
> +
> +   HCALL with return error type "H_AUTHORITY", can be resolved 
> during
> +   runtime by setting "Enable Performance Information 
> Collection" option.
> +
> + * The end user reading this sysfs file must decode the content 
> as per
> +   underlying platform/firmware.
> +
> + Possible error codes while reading this sysfs file:
> +
> + * "-EPERM" : Partition is not permitted to retrieve performance 
> information,
> + required to set "Enable Performance Information 
> Collection" option.
> +
> + * "-EIO" : Can't retrieve system information because of invalid 
> buffer length/invalid address
> +or because of some hardware error. Refer 
> getPerfCountInfo documentation for
> +more information.
> +
> + * "-EFBIG" : System information exceeds PAGE_SIZE.

-- 
~Randy

Re: [PATCH 01/79] fs: add ctime accessors infrastructure

[Randy Dunlap]

Hi Jeff,

On arch/um/, (subarch i386 or x86_64), hostfs build fails with:

../fs/hostfs/hostfs_kern.c:520:36: error: incompatible type for arg
ument 2 of 'inode_set_ctime_to_ts'
../include/linux/fs.h:1499:73: note: expected 'struct timespec64' b
ut argument is of type 'const struct hostfs_timespec *'


-- 
~Randy

Re: [PATCH v2 18/18] fbdev: Document that framebuffer_alloc() returns zero'ed data

[Randy Dunlap]

On 7/13/23 06:21, Miguel Ojeda wrote:
> On Thu, Jul 13, 2023 at 3:03 PM Thomas Zimmermann  wrote:
>>
>> Most fbdev drivers depend on framebuffer_alloc() to initialize the
>> allocated memory to 0. Document this guarantee.
>>
>> Suggested-by: Miguel Ojeda 
>> Signed-off-by: Thomas Zimmermann 
>> Cc: Helge Deller 
> 
> Thanks for sending this! Maybe this would be best earlier in the
> series, so that later patches make more sense (since they use the
> guarantee), but it is not a big deal.
> 
>> + * aligned to sizeof(long). Both, the instance of struct fb_info and
>> + * the driver private data, are cleared to zero.
> 
> I think both commas may be best omitted (but I am not a native speaker).

Yes, it would be better to omit them.

> Reviewed-by: Miguel Ojeda 
> 
> Cheers,
> Miguel

-- 
~Randy

Re: linux-next: Tree for Jul 13 (drivers/video/fbdev/ps3fb.c)

[Randy Dunlap]

On 7/12/23 19:37, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20230712:
> 

on ppc64:

In file included from ../include/linux/device.h:15,
 from ../arch/powerpc/include/asm/io.h:22,
 from ../include/linux/io.h:13,
 from ../include/linux/irq.h:20,
 from ../arch/powerpc/include/asm/hardirq.h:6,
 from ../include/linux/hardirq.h:11,
 from ../include/linux/interrupt.h:11,
 from ../drivers/video/fbdev/ps3fb.c:25:
../drivers/video/fbdev/ps3fb.c: In function 'ps3fb_probe':
../drivers/video/fbdev/ps3fb.c:1172:40: error: 'struct fb_info' has no member 
named 'dev'
 1172 |  dev_driver_string(info->dev), dev_name(info->dev),
  |^~
../include/linux/dev_printk.h:110:37: note: in definition of macro 
'dev_printk_index_wrap'
  110 | _p_func(dev, fmt, ##__VA_ARGS__);   
\
  | ^~~
../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
 1171 | dev_info(info->device, "%s %s, using %u KiB of video memory\n",
  | ^~~~
../drivers/video/fbdev/ps3fb.c:1172:61: error: 'struct fb_info' has no member 
named 'dev'
 1172 |  dev_driver_string(info->dev), dev_name(info->dev),
  | ^~
../include/linux/dev_printk.h:110:37: note: in definition of macro 
'dev_printk_index_wrap'
  110 | _p_func(dev, fmt, ##__VA_ARGS__);   
\
  | ^~~
../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
 1171 | dev_info(info->device, "%s %s, using %u KiB of video memory\n",
  | ^~~~


Full randconfig file is attached.
-- 
~Randy

config-r3073.gz
Description: application/gzip

Re: linux-next: Tree for Jul 13 (drivers/video/fbdev/ps3fb.c)

[Randy Dunlap]

Thomas,

On 7/13/23 09:11, Randy Dunlap wrote:
> 
> 
> On 7/12/23 19:37, Stephen Rothwell wrote:
>> Hi all,
>>

I still see this build error on linux-next  20230714.

>> Changes since 20230712:
>>
> 
> on ppc64:
> 
> In file included from ../include/linux/device.h:15,
>  from ../arch/powerpc/include/asm/io.h:22,
>  from ../include/linux/io.h:13,
>  from ../include/linux/irq.h:20,
>  from ../arch/powerpc/include/asm/hardirq.h:6,
>  from ../include/linux/hardirq.h:11,
>  from ../include/linux/interrupt.h:11,
>  from ../drivers/video/fbdev/ps3fb.c:25:
> ../drivers/video/fbdev/ps3fb.c: In function 'ps3fb_probe':
> ../drivers/video/fbdev/ps3fb.c:1172:40: error: 'struct fb_info' has no member 
> named 'dev'
>  1172 |  dev_driver_string(info->dev), dev_name(info->dev),
>   |^~
> ../include/linux/dev_printk.h:110:37: note: in definition of macro 
> 'dev_printk_index_wrap'
>   110 | _p_func(dev, fmt, ##__VA_ARGS__); 
>   \
>   | ^~~
> ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
>  1171 | dev_info(info->device, "%s %s, using %u KiB of video 
> memory\n",
>   | ^~~~
> ../drivers/video/fbdev/ps3fb.c:1172:61: error: 'struct fb_info' has no member 
> named 'dev'
>  1172 |  dev_driver_string(info->dev), dev_name(info->dev),
>   | ^~
> ../include/linux/dev_printk.h:110:37: note: in definition of macro 
> 'dev_printk_index_wrap'
>   110 | _p_func(dev, fmt, ##__VA_ARGS__); 
>   \
>   | ^~~
> ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
>  1171 | dev_info(info->device, "%s %s, using %u KiB of video 
> memory\n",
>   | ^~~~
> 
> 
> Full randconfig file is attached.

-- 
~Randy

Re: linux-next: Tree for Jul 13 (drivers/video/fbdev/ps3fb.c)

[Randy Dunlap]

Hi Thomas,
On 7/14/23 13:46, Randy Dunlap wrote:
> Thomas,
>
> On 7/13/23 09:11, Randy Dunlap wrote:
>>
>>
>> On 7/12/23 19:37, Stephen Rothwell wrote:
>>> Hi all,
>>>
>
> I still see this build error on linux-next 20230714.

I still see this build error on linux-next 20230717.

>
>>> Changes since 20230712:
>>>
>>
>> on ppc64:
>>
>> In file included from ../include/linux/device.h:15,
>> from ../arch/powerpc/include/asm/io.h:22,
>> from ../include/linux/io.h:13,
>> from ../include/linux/irq.h:20,
>> from ../arch/powerpc/include/asm/hardirq.h:6,
>> from ../include/linux/hardirq.h:11,
>> from ../include/linux/interrupt.h:11,
>> from ../drivers/video/fbdev/ps3fb.c:25:
>> ../drivers/video/fbdev/ps3fb.c: In function 'ps3fb_probe':
>> ../drivers/video/fbdev/ps3fb.c:1172:40: error: 'struct fb_info' has no 
>> member named 'dev'
>> 1172 | dev_driver_string(info->dev), dev_name(info->dev),
>> | ^~
>> ../include/linux/dev_printk.h:110:37: note: in definition of macro 
>> 'dev_printk_index_wrap'
>> 110 | _p_func(dev, fmt, ##__VA_ARGS__); \
>> | ^~~
>> ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info'
>> 1171 | dev_info(info->device, "%s %s, using %u KiB of video memory\n",
>> | ^~~~
>> ../drivers/video/fbdev/ps3fb.c:1172:61: error: 'struct fb_info' has no 
>> member named 'dev'
>> 1172 | dev_driver_string(info->dev), dev_name(info->dev),
>> | ^~
>> ../include/linux/dev_printk.h:110:37: note: in definition of macro 
>> 'dev_printk_index_wrap'

-- 
~Randy [using gmail temporarily while infradead is down]

Re: linux-next: Tree for Jul 13 (drivers/video/fbdev/ps3fb.c)

[Randy Dunlap]

On 7/18/23 04:48, Michael Ellerman wrote:
> Bagas Sanjaya  writes:
>> On Thu, Jul 13, 2023 at 09:11:10AM -0700, Randy Dunlap wrote:
>>> on ppc64:
>>>
>>> In file included from ../include/linux/device.h:15,
>>>  from ../arch/powerpc/include/asm/io.h:22,
>>>  from ../include/linux/io.h:13,
>>>  from ../include/linux/irq.h:20,
>>>  from ../arch/powerpc/include/asm/hardirq.h:6,
>>>  from ../include/linux/hardirq.h:11,
>>>  from ../include/linux/interrupt.h:11,
>>>  from ../drivers/video/fbdev/ps3fb.c:25:
>>> ../drivers/video/fbdev/ps3fb.c: In function 'ps3fb_probe':
>>> ../drivers/video/fbdev/ps3fb.c:1172:40: error: 'struct fb_info' has no 
>>> member named 'dev'
>>>  1172 |  dev_driver_string(info->dev), dev_name(info->dev),
>>>   |^~
>>> ../include/linux/dev_printk.h:110:37: note: in definition of macro 
>>> 'dev_printk_index_wrap'
>>>   110 | _p_func(dev, fmt, ##__VA_ARGS__);   
>>> \
>>>   | ^~~
>>> ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 
>>> 'dev_info'
>>>  1171 | dev_info(info->device, "%s %s, using %u KiB of video 
>>> memory\n",
>>>   | ^~~~
>>> ../drivers/video/fbdev/ps3fb.c:1172:61: error: 'struct fb_info' has no 
>>> member named 'dev'
>>>  1172 |  dev_driver_string(info->dev), dev_name(info->dev),
>>>   | ^~
>>> ../include/linux/dev_printk.h:110:37: note: in definition of macro 
>>> 'dev_printk_index_wrap'
>>>   110 | _p_func(dev, fmt, ##__VA_ARGS__);   
>>> \
>>>   | ^~~
>>> ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 
>>> 'dev_info'
>>>  1171 | dev_info(info->device, "%s %s, using %u KiB of video 
>>> memory\n",
>>>   | ^~~~
>>>
>>>
>>
>> Hmm, there is no response from Thomas yet. I guess we should go with
>> reverting bdb616479eff419, right? Regardless, I'm adding this build 
>> regression
>> to regzbot so that parties involved are aware of it:
>>
>> #regzbot ^introduced: bdb616479eff419
>> #regzbot title: build regression in PS3 framebuffer
> 
> Does regzbot track issues in linux-next?
> 
> They're not really regressions because they're not in a release yet.
> 
> Anyway I don't see where bdb616479eff419 comes from.
> 
> The issue was introduced by:
> 
>   701d2054fa31 fbdev: Make support for userspace interfaces configurable
> 
> The driver seems to only use info->dev in that one dev_info() line,
> which seems purely cosmetic, so I think it could just be removed, eg:
> 
> diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
> index d4abcf8aff75..a304a39d712b 100644
> --- a/drivers/video/fbdev/ps3fb.c
> +++ b/drivers/video/fbdev/ps3fb.c
> @@ -1168,8 +1168,7 @@ static int ps3fb_probe(struct ps3_system_bus_device 
> *dev)
>  
>   ps3_system_bus_set_drvdata(dev, info);
>  
> - dev_info(info->device, "%s %s, using %u KiB of video memory\n",
> -  dev_driver_string(info->dev), dev_name(info->dev),
> + dev_info(info->device, "using %u KiB of video memory\n",
>info->fix.smem_len >> 10);
>  
>   task = kthread_run(ps3fbd, info, DEVICE_NAME);


Tested-by: Randy Dunlap  # build-tested

Thanks.

-- 
~Randy

[PATCH] Documentation: devices.txt: reconcile serial/ucc_uart minor numers

[Randy Dunlap]

Reconcile devices.txt with serial/ucc_uart.c regarding device number
assignments. ucc_uart.c supports 4 ports and uses minor devnums
46-49, so update devices.txt with that info.
Then update ucc_uart.c's reference to the location of the devices.txt
list in the kernel source tree.

Fixes: d7584ed2b994 ("[POWERPC] qe-uart: add support for Freescale QUICCEngine 
UART")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Randy Dunlap 
Cc: Timur Tabi 
Cc: Kumar Gala 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-ser...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/admin-guide/devices.txt |2 +-
 drivers/tty/serial/ucc_uart.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff -- a/drivers/tty/serial/ucc_uart.c b/drivers/tty/serial/ucc_uart.c
--- a/drivers/tty/serial/ucc_uart.c
+++ b/drivers/tty/serial/ucc_uart.c
@@ -59,7 +59,7 @@ static int firmware_loaded;
 /* #define LOOPBACK */
 
 /* The major and minor device numbers are defined in
- * http://www.lanana.org/docs/device-list/devices-2.6+.txt.  For the QE
+ * Documentation/admin-guide/devices.txt.  For the QE
  * UART, we have major number 204 and minor numbers 46 - 49, which are the
  * same as for the CPM2.  This decision was made because no Freescale part
  * has both a CPM and a QE.
diff -- a/Documentation/admin-guide/devices.txt 
b/Documentation/admin-guide/devices.txt
--- a/Documentation/admin-guide/devices.txt
+++ b/Documentation/admin-guide/devices.txt
@@ -2691,7 +2691,7 @@
 45 = /dev/ttyMM1   Marvell MPSC - port 1 (obsolete 
unused)
 46 = /dev/ttyCPM0  PPC CPM (SCC or SMC) - port 0
...
-47 = /dev/ttyCPM5  PPC CPM (SCC or SMC) - port 5
+49 = /dev/ttyCPM5  PPC CPM (SCC or SMC) - port 3
 50 = /dev/ttyIOC0  Altix serial card
...
 81 = /dev/ttyIOC31 Altix serial card

Re: linux-next: Tree for Jul 24 (arch/powerpc/platforms/embedded6xx/mvme5100.c)

[Randy Dunlap]

On 7/23/23 21:08, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20230721:
> 

on ppc32:

../arch/powerpc/platforms/embedded6xx/mvme5100.c: In function 
'mvme5100_add_bridge':
../arch/powerpc/platforms/embedded6xx/mvme5100.c:135:65: error: passing 
argument 5 of 'early_read_config_dword' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  135 | early_read_config_dword(hose, 0, 0, PCI_BASE_ADDRESS_1, 
&pci_membase);
  | 
^~~~
  | |
  | 
phys_addr_t * {aka long long unsigned int *}
In file included from ../arch/powerpc/platforms/embedded6xx/mvme5100.c:19:
../arch/powerpc/include/asm/pci-bridge.h:150:53: note: expected 'u32 *' {aka 
'unsigned int *'} but argument is of type 'phys_addr_t *' {aka 'long long 
unsigned int *'}
  150 | int dev_fn, int where, u32 *val);
  |~^~~
In file included from ../include/asm-generic/bug.h:22,
 from ../arch/powerpc/include/asm/bug.h:116,
 from ../include/linux/bug.h:5,
 from ../include/linux/thread_info.h:13,
 from ../include/asm-generic/preempt.h:5,
 from ./arch/powerpc/include/generated/asm/preempt.h:1,
 from ../include/linux/preempt.h:79,
 from ../include/linux/spinlock.h:56,
 from ../include/linux/irq.h:14,
 from ../include/linux/of_irq.h:7,
 from ../arch/powerpc/platforms/embedded6xx/mvme5100.c:15:
../include/linux/kern_levels.h:5:25: warning: format '%x' expects argument of 
type 'unsigned int', but argument 2 has type 'phys_addr_t' {aka 'long long 
unsigned int'} [-Wformat=]
5 | #define KERN_SOH"\001"  /* ASCII Start Of Header */
  | ^~
../include/linux/printk.h:427:25: note: in definition of macro 
'printk_index_wrap'
  427 | _p_func(_fmt, ##__VA_ARGS__);   
\
  | ^~~~
../include/linux/printk.h:528:9: note: in expansion of macro 'printk'
  528 | printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
  | ^~
../include/linux/kern_levels.h:14:25: note: in expansion of macro 'KERN_SOH'
   14 | #define KERN_INFO   KERN_SOH "6"/* informational */
  | ^~~~
../include/linux/printk.h:528:16: note: in expansion of macro 'KERN_INFO'
  528 | printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
  |^
../arch/powerpc/platforms/embedded6xx/mvme5100.c:142:9: note: in expansion of 
macro 'pr_info'
  142 | pr_info("mvme5100_pic_init: pci_membase: %x\n", pci_membase);
  | ^~~
cc1: some warnings being treated as errors


Full randconfig file is attached.

-- 
~Randy

config-r3694.gz
Description: application/gzip