Re: kernel-4.15.0-0.rc3.git0.1.fc28 src rpm fails to compile because of errors in ppc64p7 config file

[Peter Robinson]

>> On Wed, Dec 13, 2017 at 8:08 PM, Laura Abbott 
>> wrote:
>
>> > Can you share the steps you used to produce this build as well as
>> > the full build log? As you noted, this was built successfully in
>> > koji.
>
> I'm following this procedure for building from the src.rpm using
> rpmbuild.
>
> https://fedoraproject.org/wiki/Building_a_custom_kernel/Source_RPM
>
> I've been using it for years, and I successfully built a 4.15 kernel
> just a few weeks ago using the same procedure.
>
>> The ppc64p7 sub variant was removed so I'm not even sure why that's
>> showing up.
>
> This was the key comment.  It seems that the kernel picks up any kernel
> config files in SOURCES.  There was an old set of configs for ppc64p7
> there.  Once I deleted them, everything worked fine.  The previous
> version of 4.15 I successfully built was in F25, and I'm now building in
> rawhide, and it had the obsolete ppc64p7 config file I SOURCES from
> older builds.
>
> Sorry for the noise, but thanks for the help.

No issues, I always find "git status" is a big help here with kernel
stuff, especially when it comes to stuff that might be generated.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: kernel-4.15.0-0.rc3.git0.1.fc28 src rpm fails to compile because of errors in ppc64p7 config file

[stan]

On Thu, 14 Dec 2017 01:00:10 +
Peter Robinson  wrote:

> On Wed, Dec 13, 2017 at 8:08 PM, Laura Abbott 
> wrote:

> > Can you share the steps you used to produce this build as well as
> > the full build log? As you noted, this was built successfully in
> > koji.  

I'm following this procedure for building from the src.rpm using
rpmbuild.

https://fedoraproject.org/wiki/Building_a_custom_kernel/Source_RPM

I've been using it for years, and I successfully built a 4.15 kernel
just a few weeks ago using the same procedure.

> The ppc64p7 sub variant was removed so I'm not even sure why that's
> showing up.

This was the key comment.  It seems that the kernel picks up any kernel
config files in SOURCES.  There was an old set of configs for ppc64p7
there.  Once I deleted them, everything worked fine.  The previous
version of 4.15 I successfully built was in F25, and I'm now building in
rawhide, and it had the obsolete ppc64p7 config file I SOURCES from
older builds.

Sorry for the noise, but thanks for the help.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 1/2] configs: Move base-debug and base-generic to configs/fedora

[Don Zickus]

It was suggested that base-debug and base-generic were not good names
to use.  Further discussion led to using configs/fedora for the base
config files and configs/rhel for any overrides.

This patch does a plain

mkdir configs/fedora
git mv configs/base-{generic,debug} configs/fedora

No code changes.
---


___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 2/2] configs: Update config generation script to use configs/fedora

[Don Zickus]

The previous patch moved the configs/base-{generic,debug} to configs/fedora.
Now we update the scripts to reflect that change.  Changing the scripts
was straightforward.  Handling overrides that didn't use generic names
was a little trickier.

To handle random override names (well rhel), I added some extra logic
in the config_generation script called "ORDER".  This tells the scripts
which configs to lay down first and which one overrides it.

Through some testing, I realized I could simplify things and just create
an outer 'order' loop.  This removed some duplicated code.

The other change is the 'skip_if_missing' flag.  The overrides directory
will not mimic the baseline directory layout 100%.  Ensure the baseline
config files are all there, but allow the overrides to have missing files.

Tested on my Fedora and my RHEL tree with success.
---
 configs/build_configs.sh  | 62 ---
 configs/config_generation |  5 
 2 files changed, 37 insertions(+), 30 deletions(-)

diff --git a/configs/build_configs.sh b/configs/build_configs.sh
index f345e2af..15ab6b38 100755
--- a/configs/build_configs.sh
+++ b/configs/build_configs.sh
@@ -6,7 +6,7 @@
 
 PACKAGE_NAME="${1:-kernel}" # defines the package name used
 KVERREL="${2:-}"
-SUBARCH="${3:-}" # defines a specific arch for use with rh-configs-arch-prep 
target
+SUBARCH="${3:-}" # defines a specific arch
 SCRIPT="$(readlink -f $0)"
 OUTPUT_DIR="$PWD"
 SCRIPT_DIR="$(dirname $SCRIPT)"
@@ -49,29 +49,31 @@ function merge_configs()
archvar=$1
arch=$(echo "$archvar" | cut -f1 -d"-")
configs=$2
+   order=$3
name=$OUTPUT_DIR/$PACKAGE_NAME-$archvar.config
echo -n "Building $name ... "
touch config-merging config-merged
 
-   # apply base first
-   for config in $(echo $configs | sed -e 's/:/ /g')
+   # apply based on order
+   skip_if_missing=""
+   for o in $order
do
-   perl merge.pl config-base-$config config-merging > config-merged
-   if [ ! $? -eq 0 ]; then
-   die "Failed to merge base"
-   fi
-   mv config-merged config-merging
-   done
-   for config in $(echo $configs | sed -e 's/:/ /g')
-   do
-   # not all override files exist
-   test -e config-$config || continue
-
-   perl merge.pl config-$config config-merging > config-merged
-   if [ ! $? -eq 0 ]; then
-   die "Failed to merge configs"
-   fi
-   mv config-merged config-merging
+   for config in $(echo $configs | sed -e 's/:/ /g')
+   do
+   cfile="config-$o-$config"
+
+   test -n "$skip_if_missing" && test ! -e $cfile && 
continue
+
+   perl merge.pl $cfile config-merging > config-merged
+   if [ ! $? -eq 0 ]; then
+   die "Failed to merge $cfile"
+   fi
+   mv config-merged config-merging
+   done
+
+   # first configs in $order is baseline, all files should be
+   # there.  second pass is overrides and can be missing.
+   skip_if_missing="1"
done
if [ "x$arch" == "xaarch64" ]; then
echo "# arm64" > $name
@@ -93,22 +95,22 @@ function merge_configs()
echo "done"
 }
 
-glist=$(find base-generic -type d)
-dlist=$(find base-debug -type d)
-gllist=$(test -d generic && find generic -type d)
-dllist=$(test -d debug && find debug -type d)
-
-for d in $glist $dlist $gllist $dllist
-do
-   combine_config_layer $d
-done
-
 while read line
 do
if [ $(echo "$line" | grep -c "^#") -ne 0 ]; then
continue
elif [ $(echo "$line" | grep -c "^$") -ne 0 ]; then
continue
+   elif [ $(echo "$line" | grep -c "^ORDER") -ne 0 ]; then
+   order=$(echo "$line" | cut -f2 -d"=")
+   for o in $order
+   do
+   glist=$(find $o -type d)
+   for d in $glist
+   do
+   combine_config_layer $d
+   done
+   done
else
arch=$(echo "$line" | cut -f1 -d"=")
configs=$(echo "$line" | cut -f2 -d"=")
@@ -117,7 +119,7 @@ do
continue
fi
 
-   merge_configs $arch $configs
+   merge_configs $arch $configs "$order"
fi
 done < $control_file
 
diff --git a/configs/config_generation b/configs/config_generation
index b88a5ea9..e8614c43 100644
--- a/configs/config_generation
+++ b/configs/config_generation
@@ -3,6 +3,11 @@
 # the first arg is arch and variant, the second is a hierarchy of
 # config options, lowest priority to highest
 
+# tells the build_configs.sh which order to build the 

Re: Enabling CONFIG_REGULATOR on x86_64

[Laura Abbott]

On 12/13/2017 01:26 AM, Hans de Goede wrote:

Hi,

On 13-12-17 10:24, Hans de Goede wrote:

Hi All,

I would like to enable CONFIG_REGULATOR on x86_64, to fix
USB PD negotiating (and charging with more the 0.5 A in
general) and battery monitoring on Intel Cherry Trail
devices which use an Intel PMIC + FUSB302 Type-C controller
to enable USB-PD charging.

Since the USB-PD negotiation in this case is handled by
the kernel rather then by firmware in the Alpine Ridge
controller, the kernel also needs to enable/disable
the 5V boost converter feeding 5v to the Type-C port
when it is in host / power-source mode and this is
modeled as a regulator.

One of the drivers for the complex of 4 ICs which
implement the Type-C and battery charging monitoring
on these devices has a Kconfig dep on CONFIG_REGULATOR
because of this and without this driver these devices
are limited to charging (or rather slowly discharging)
at 5V 0.5A rather then charging at up to 12V 3A, also
without this battery monitoring will not work and the
kernel will be unable to make the port provide 5V
when a Type-C to USB-A-receptacle cable gets plugged in.

Downside of this is a slightly bigger kernel (the
regulator framework is tiny) and some messages like
these when some drivers load:

[   19.955279] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply avdd not found, 
using dummy regulator
[   19.955331] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply cpvdd not found, 
using dummy regulator

As these drivers now actually call into the regulator
framework which prints these messages, rather then calling
empty stubs.

These are printed at "warning" level so will not show
up on the console.

So if there are no objections I will push a commit
enabling CONFIG_REGULATOR on x86_64 one of the coming
days.


p.s.

I'm proposing this change for the 4.15 kernel only, as that finally
has all the necessary drivers to do USB PD on these devices
and enabling CONFIG_REGULATOR on x86_64 is all that is missing
to get this to work.

Regards,

Hans


This sounds okay for rawhide. The regulator framework has been
well tested and I wouldn't expect too many problems.

Thanks,
Laura
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Changing the SND_HDA_POWER_SAVE_DEFAULT option from 0 to 1

[Jeremy Cline]

On 11/03/2017 04:59 AM, Hans de Goede wrote:
> Hi,
> 
> On 01-11-17 20:34, Laura Abbott wrote:
>> I'm always a bit uneasy about enabling hardware power saving
>> since it rarely seems to be done correctly but as Peter pointed
>> out it's easy to revert if something goes wrong. Having the
>> endorsement of upstream is also good since it means they should
>> be responsive.
>>
>> Enabling for 4.14 sounds like a good plan. Did you intend for
>> this to end up in stable releases on rebase?
> 
> That was my original intention yes. But now that you explicitly
> ask I guess that we may want to hold off on that and just
> make the change for rawhide / F28. I will try to get the
> change committed to the master branch today (otherwise
> I will do it Monday). I will leave it up to you if you also
> make the change to the stable releases on rebase.
We ended up putting this in the 4.14 rebase and there were a few issues
reported[0][1] on i686 and x86_64 so I've set it back to 0 on all arches
in F27 and F26. Hans, do you want to leave in on in Rawhide and see if
we can come up with some fixes or should I switch it to 0 there as well?

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1525561
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1525104

Thanks,
Jeremy
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: kernel-4.15.0-0.rc3.git0.1.fc28 src rpm fails to compile because of errors in ppc64p7 config file

[Laura Abbott]

On 12/13/2017 10:25 AM, stan wrote:


I tried to compile this kernel from the src rpm on rawhide.  I kept
getting the error that two config options for ppc64p7 were set to m,
and m wasn't a valid choice.

So, I generated the following patch,

diff --git a/configs/kernel-4.15.0-ppc64p7.config
b/configs/kernel-4.15.0-ppc64p7.config index 18f4b44..ca5b410 100644
--- a/configs/kernel-4.15.0-ppc64p7.config
+++ b/configs/kernel-4.15.0-ppc64p7.config
@@ -1704,7 +1704,7 @@ CONFIG_HW_RANDOM_TIMERIOMEM=m
  CONFIG_HW_RANDOM_TPM=m
  CONFIG_HW_RANDOM_VIRTIO=m
  CONFIG_HW_RANDOM=y
-CONFIG_HWSPINLOCK=m
+CONFIG_HWSPINLOCK=y
  CONFIG_HYSDN_CAPI=y
  CONFIG_HYSDN=m
  CONFIG_HZ=100
@@ -4447,7 +4447,7 @@ CONFIG_SND_DARLA24=m
  # CONFIG_SND_DEBUG_VERBOSE is not set
  CONFIG_SND_DEBUG=y
  CONFIG_SND_DESIGNWARE_I2S=m
-CONFIG_SND_DESIGNWARE_PCM=m
+CONFIG_SND_DESIGNWARE_PCM=y
  CONFIG_SND_DICE=m
  CONFIG_SND_DMAENGINE_PCM=m
  CONFIG_SND_DRIVERS=y

I don't know if y is a valid setting for a ppc for those options, but I
presume if m was desired, y would succeed.  I don't really care about
ppc64p7 as I'm building for x86_64.  I changed the spec file so that
this architecture won't be built in nobuildarches, and this error still
occurred.

Unfortunately, at the time that the kernel is patched, this config file
doesn't exist yet, and so the patch fails.  I see a successful build in
koji; I'm not sure how that can be.

What is the best way to proceed from here?


Can you share the steps you used to produce this build as well as the
full build log? As you noted, this was built successfully in koji.

Thanks,
Laura
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

kernel-4.15.0-0.rc3.git0.1.fc28 src rpm fails to compile because of errors in ppc64p7 config file

[stan]

I tried to compile this kernel from the src rpm on rawhide.  I kept
getting the error that two config options for ppc64p7 were set to m,
and m wasn't a valid choice.

So, I generated the following patch,

diff --git a/configs/kernel-4.15.0-ppc64p7.config
b/configs/kernel-4.15.0-ppc64p7.config index 18f4b44..ca5b410 100644
--- a/configs/kernel-4.15.0-ppc64p7.config
+++ b/configs/kernel-4.15.0-ppc64p7.config
@@ -1704,7 +1704,7 @@ CONFIG_HW_RANDOM_TIMERIOMEM=m
 CONFIG_HW_RANDOM_TPM=m
 CONFIG_HW_RANDOM_VIRTIO=m
 CONFIG_HW_RANDOM=y
-CONFIG_HWSPINLOCK=m
+CONFIG_HWSPINLOCK=y
 CONFIG_HYSDN_CAPI=y
 CONFIG_HYSDN=m
 CONFIG_HZ=100
@@ -4447,7 +4447,7 @@ CONFIG_SND_DARLA24=m
 # CONFIG_SND_DEBUG_VERBOSE is not set
 CONFIG_SND_DEBUG=y
 CONFIG_SND_DESIGNWARE_I2S=m
-CONFIG_SND_DESIGNWARE_PCM=m
+CONFIG_SND_DESIGNWARE_PCM=y
 CONFIG_SND_DICE=m
 CONFIG_SND_DMAENGINE_PCM=m
 CONFIG_SND_DRIVERS=y

I don't know if y is a valid setting for a ppc for those options, but I
presume if m was desired, y would succeed.  I don't really care about
ppc64p7 as I'm building for x86_64.  I changed the spec file so that
this architecture won't be built in nobuildarches, and this error still
occurred.

Unfortunately, at the time that the kernel is patched, this config file
doesn't exist yet, and so the patch fails.  I see a successful build in
koji; I'm not sure how that can be.

What is the best way to proceed from here?

Thanks.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Enabling CONFIG_REGULATOR on x86_64

[Hans de Goede]

Hi All,

I would like to enable CONFIG_REGULATOR on x86_64, to fix
USB PD negotiating (and charging with more the 0.5 A in
general) and battery monitoring on Intel Cherry Trail
devices which use an Intel PMIC + FUSB302 Type-C controller
to enable USB-PD charging.

Since the USB-PD negotiation in this case is handled by
the kernel rather then by firmware in the Alpine Ridge
controller, the kernel also needs to enable/disable
the 5V boost converter feeding 5v to the Type-C port
when it is in host / power-source mode and this is
modeled as a regulator.

One of the drivers for the complex of 4 ICs which
implement the Type-C and battery charging monitoring
on these devices has a Kconfig dep on CONFIG_REGULATOR
because of this and without this driver these devices
are limited to charging (or rather slowly discharging)
at 5V 0.5A rather then charging at up to 12V 3A, also
without this battery monitoring will not work and the
kernel will be unable to make the port provide 5V
when a Type-C to USB-A-receptacle cable gets plugged in.

Downside of this is a slightly bigger kernel (the
regulator framework is tiny) and some messages like
these when some drivers load:

[   19.955279] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply avdd not found, 
using dummy regulator
[   19.955331] rt5645 i2c-10EC5645:00: i2c-10EC5645:00 supply cpvdd not found, 
using dummy regulator

As these drivers now actually call into the regulator
framework which prints these messages, rather then calling
empty stubs.

These are printed at "warning" level so will not show
up on the console.

So if there are no objections I will push a commit
enabling CONFIG_REGULATOR on x86_64 one of the coming
days.

Regards,

Hans
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org