Re: [linux-yocto] [PATCH v4.14] linux-yocto: Fix the Ethernet broken on mpc8315e-rdb board

2018-03-21 Thread Bruce Ashfield 

On 03/21/2018 02:32 AM, Kevin Hao wrote:

This patch series fix the Ethernet broken on the mpc8315erdb board introduced
by commit b6b5e8a69118 ("gianfar: Disable EEE autoneg by default").

The two kernel patches are based some suggestions from Andrew Lunn(PHY 
maintainer),
and I have sent them to netdev mail list, and get no objection so far.


Good enough for me.

I've merged these changes and will send SRCREV updates in a day or so.

If there are any changes based on the upstream comments, send additional
patches.

Bruce



Thanks,
Kevin



--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [kernel-cache][PATCH] features/wifi: Add WiFi driver fragments for various vendors/interfaces

2018-03-21 Thread Bruce Ashfield 

On 03/20/2018 10:10 AM, Nathan Rossi wrote:

This change adds WiFi driver configuration fragments. The fragments are
split into vendor and interface files to allow for easy selection of
drivers for specific interface types (USB, PCI, SDIO) which is useful
for BSPs with specific interfaces. The specific vendor/interface config
fragments can be included by specific BSPs in its .scc files.

However .scc files (wifi-*.scc) are provided to allow enabling interface
specific or all interfaces drivers via KERNEL_FEATURES or inclusion via
other .scc files. And wifi-common.scc is provided to enable the base
config options required for all WiFi drivers, which is done to ensure
correct configuration for default no config setups (e.g.
linux-yocto-tiny).

This patch only enables a limited set of drivers, which is based on what
the common-pc-wifi.cfg fragment sets as well as some additional drivers,
that primarily appear in USB WiFi devices.



These changes look good to me. I'll let them sit on the list for
another day or so, and see if anyone else has any comments.



Signed-off-by: Nathan Rossi 
---
These changes are very similar to a set of configuration fragments that
were included (?) in minnow branches in ~2013. However they never made
it into the current set of configuration fragments.

https://lists.yoctoproject.org/pipermail/linux-yocto/2013-November/001393.html


Interesting. I'm not sure how they ended up getting dropped or
lost, but when I merge this, it will go into the versioned
branches and master, so it can't be lost again.



Also whilst not in this patch, if accepted these fragments could replace
the common-pc-wifi.cfg to reduce duplication.


Indeed. We can look at that in follow up commits.



For completeness I have tested these fragments on linux-yocto version
v4.14 and v4.15 for qemux86, qemux86-64 and qemuarm builds as well as
for the beaglebone-yocto target. For v4.12 compatibility, due to the
iwlwifi fragments adding patches (which do not apply correctly to
standard/base) the fragments would need to be modified.


What configuration were you building to trigger those errors ? Just
qemux86-64 ? something else ? The patches should have been ignored,
as long as the fragment wasn't directly on the SRC_URI.

Bruce


---
  features/wifi/atheros-pci.cfg   | 11 +++
  features/wifi/atheros-usb.cfg   |  8 
  features/wifi/broadcom-pci.cfg  | 11 +++
  features/wifi/broadcom-sdio.cfg | 11 +++
  features/wifi/broadcom-usb.cfg  |  7 +++
  features/wifi/mediatek-pci.cfg  |  3 +++
  features/wifi/mediatek-usb.cfg  |  3 +++
  features/wifi/ralink-pci.cfg| 15 +++
  features/wifi/ralink-usb.cfg| 12 
  features/wifi/realtek-pci.cfg   | 18 ++
  features/wifi/realtek-usb.cfg   | 11 +++
  features/wifi/wifi-all.scc  |  7 +++
  features/wifi/wifi-common.cfg   |  4 
  features/wifi/wifi-common.scc   |  7 +++
  features/wifi/wifi-pci.scc  | 14 ++
  features/wifi/wifi-sdio.scc |  7 +++
  features/wifi/wifi-usb.scc  | 11 +++
  17 files changed, 160 insertions(+)
  create mode 100644 features/wifi/atheros-pci.cfg
  create mode 100644 features/wifi/atheros-usb.cfg
  create mode 100644 features/wifi/broadcom-pci.cfg
  create mode 100644 features/wifi/broadcom-sdio.cfg
  create mode 100644 features/wifi/broadcom-usb.cfg
  create mode 100644 features/wifi/mediatek-pci.cfg
  create mode 100644 features/wifi/mediatek-usb.cfg
  create mode 100644 features/wifi/ralink-pci.cfg
  create mode 100644 features/wifi/ralink-usb.cfg
  create mode 100644 features/wifi/realtek-pci.cfg
  create mode 100644 features/wifi/realtek-usb.cfg
  create mode 100644 features/wifi/wifi-all.scc
  create mode 100644 features/wifi/wifi-common.cfg
  create mode 100644 features/wifi/wifi-common.scc
  create mode 100644 features/wifi/wifi-pci.scc
  create mode 100644 features/wifi/wifi-sdio.scc
  create mode 100644 features/wifi/wifi-usb.scc

diff --git a/features/wifi/atheros-pci.cfg b/features/wifi/atheros-pci.cfg
new file mode 100644
index 00..1c48a0528a
--- /dev/null
+++ b/features/wifi/atheros-pci.cfg
@@ -0,0 +1,11 @@
+CONFIG_WLAN_VENDOR_ATH=y
+
+# ath5k
+CONFIG_ATH5K=m
+
+# ath9k
+CONFIG_ATH9K=m
+CONFIG_ATH9K_RFKILL=y
+CONFIG_ATH9K_PCOEM=y
+CONFIG_ATH9K_PCI=y
+
diff --git a/features/wifi/atheros-usb.cfg b/features/wifi/atheros-usb.cfg
new file mode 100644
index 00..b9767dc164
--- /dev/null
+++ b/features/wifi/atheros-usb.cfg
@@ -0,0 +1,8 @@
+CONFIG_WLAN_VENDOR_ATH=y
+
+# ath9k
+CONFIG_ATH9K=m
+CONFIG_ATH9K_RFKILL=y
+CONFIG_ATH9K_PCOEM=y
+CONFIG_ATH9K_HTC=y
+
diff --git a/features/wifi/broadcom-pci.cfg b/features/wifi/broadcom-pci.cfg
new file mode 100644
index 00..2b5abe5842
--- /dev/null
+++ b/features/wifi/broadcom-pci.cfg
@@ -0,0 +1,11 @@
+CONFIG_WLAN_VENDOR_BROADCOM=y
+
+# brcm80211
+CONFIG_BRCMUTIL=m
+CONFIG_BRCMSMAC=m
+CONFIG_BRCMFMAC=m

[yocto] How to build two different kernel

2018-03-21 Thread HuaFu 8386 
Hi,

I want to build two different images with two different kernel configs, one
for debug version and one for production version, like
bitbake debug_image
bitbake product_image

Any idea how can I do that?

Thanks,
Danny
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Yocto Project Status WW12’18

2018-03-21 Thread Richard Purdie 
On Tue, 2018-03-20 at 20:00 +0200, Alexander Kanavin wrote:
> On 03/20/2018 05:59 PM, Richard Purdie wrote:
> > 
> > > 
> > > > 
> > > > How long does a single run take, and why not run it every
> > > > month?
> > > Just a bit longer than a day, maybe 30 hours, if it needs to
> > > update
> > > the
> > > typical amount of 100-150 packages. I'll shift it to monthly
> > > then.
> > Personally I'm leaning to every couple of weeks...
> My worry is that shorter AUH periods will lead to reminder fatigue.
> Also the period between submitting the updates, and having them show
> up in master is sometimes less than ideal, even when the freeze is
> not in effect.

Its a valid concern? Once every three weeks? I would like to make
things more available for people if possible too...

With builds we've had a bad run at the moment and am hoping with
improvements in build resources that are in process we can fix that.

Cheers,

Richard
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder][PATCH] /builders.py

2018-03-21 Thread Graydon, Tracy 
Add the releases subdirectory to the release publishing destination path.

Signed-off-by: Graydon, Tracy 
---
 builders.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builders.py b/builders.py
index 7bd218e..977d80a 100644
--- a/builders.py
+++ b/builders.py
@@ -48,7 +48,7 @@ def get_publish_dest(props):
 snapshot += "." + rc_number
 
 rel_name = "yocto-" + props.getProperty("yocto_number", "") + 
snapshot
-dest = os.path.join(config.publish_dest, rel_name)
+dest = os.path.join(config.publish_dest, "releases", rel_name)
 else:
 dest_base = os.path.join(config.publish_dest,
  props.getProperty("buildername"),
-- 
2.7.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OpenBLAS recipe

2018-03-21 Thread Matthias Schöpfer 
Hi Peter,

I got some progress using:

> export BLAS=/path/to/libblas.so
> export LAPACK=/path/to/liblapack.so
> export ATLAS=/path/to/libatlas.so

like:

export BLAS=${STAGING_LIBDIR}

turns out, my lapack does not have cblas, when I enable CBLAS, I have an
Issue with Fortran C

ERROR: lapack-3.8.0-r0 do_configure: Function failed: do_configure (log
file is located at
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/temp/log.do_configure.4609)
ERROR: Logfile of failure stored in:
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/temp/log.do_configure.4609
Log data follows:
| DEBUG: Executing shell function do_configure
| -- The Fortran compiler identification is GNU 7.3.0
| -- The C compiler identification is GNU 7.3.0
| -- Check for working Fortran compiler:
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/recipe-sysroot-native/usr/bin/x86_64-idp-linux/x86_64-idp-linux-gfortran
| -- Check for working Fortran compiler:
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/recipe-sysroot-native/usr/bin/x86_64-idp-linux/x86_64-idp-linux-gfortran
 -- works
| -- Detecting Fortran compiler ABI info
| -- Detecting Fortran compiler ABI info - done
| -- Checking whether
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/recipe-sysroot-native/usr/bin/x86_64-idp-linux/x86_64-idp-linux-gfortran
supports Fortran 90
| -- Checking whether
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/recipe-sysroot-native/usr/bin/x86_64-idp-linux/x86_64-idp-linux-gfortran
supports Fortran 90 -- yes
| -- Check for working C compiler:
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/recipe-sysroot-native/usr/bin/x86_64-idp-linux/x86_64-idp-linux-gcc
| -- Check for working C compiler:
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/recipe-sysroot-native/usr/bin/x86_64-idp-linux/x86_64-idp-linux-gcc
-- works
| -- Detecting C compiler ABI info
| -- Detecting C compiler ABI info - done
| -- Detecting C compile features
| -- Detecting C compile features - done
| -- Setting build type to 'Release' as none was specified.
| -- Looking for Python greater than 2.6 -
| -- Could NOT find PythonInterp (missing:  PYTHON_EXECUTABLE) (Required
is at least version "2.7")
| -- No suitable Python version found, so skipping summary tests.
| -- Build tests: OFF
| -- Reducing RELEASE optimization level to O2
| -- Looking for Fortran NONE - found
| -- Looking for Fortran INT_CPU_TIME - found
| -- Looking for Fortran EXT_ETIME - not found
| -- Looking for Fortran EXT_ETIME_ - not found
| -- Looking for Fortran INT_ETIME - not found
| -- --> Will use second_INT_CPU_TIME.f and dsecnd_INT_CPU_TIME.f as
timing function.
| -- Build deprecated routines: OFF
| -- Build single precision real: ON
| -- Build double precision real: ON
| -- Build single precision complex: ON
| -- Build double precision complex: ON
| -- Using supplied NETLIB BLAS implementation
| -- CBLAS enable
| -- Detecting Fortran/C Interface
| -- Detecting Fortran/C Interface - Failed to load sample executable
| -- Verifying Fortran/C Compiler Compatibility
| -- Verifying Fortran/C Compiler Compatibility - Failed
| CMake Error at
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/recipe-sysroot-native/usr/share/cmake-3.8/Modules/FortranCInterface.cmake:383
(message):
|   The Fortran compiler:
|
|
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/recipe-sysroot-native/usr/bin/x86_64-idp-linux/x86_64-idp-linux-gfortran
|
|   and the C compiler:
|
|
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/recipe-sysroot-native/usr/bin/x86_64-idp-linux/x86_64-idp-linux-gcc
|
|   failed to compile a simple test project using both languages.  The
output
|   was:
|
| Change Dir:
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/build/CMakeFiles/FortranCInterface/VerifyC
|
| Run Build
Command:"/home/mschoepf/identpro/yocto/ros-devel/tmp/hosttools/make"
"VerifyFortranC"
|
/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/recipe-sysroot-native/usr/bin/cmake
-H/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/recipe-sysroot-native/usr/share/cmake-3.8/Modules/FortranCInterface/Verify
-B/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/build/CMakeFiles/FortranCInterface/VerifyC
--check-build-system CMakeFiles/Makefile.cmake 0
| make -f CMakeFiles/Makefile2 VerifyFortranC
| make[1]: Entering directory
'/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/lapack/3.8.0-r0/build/CMakeFiles/FortranCInterface/VerifyC'
|

Re: [linux-yocto] [PATCH 077/269] kernel/irq/manage.c: Fix irq_set_affinity to allow use with buslocks

2018-03-21 Thread Bruce Ashfield 

On 03/02/2018 12:46 PM, Daniel Dragomir wrote:

From: David Mercado 

Modify irq_set_affinity() to allow usage of bus locks with "slow bus" IRQ
controllers.  This only affects those BSPs that use bus locks in their IRQ
controllers, such as the LSI Axxia GIC.  The recommendation for this
change originated from Thomax Gleixner at Linutronix.

Signed-off-by: David Mercado 
---
  kernel/irq/manage.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 425170d..ff0 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -244,16 +244,16 @@ int irq_set_affinity_locked(struct irq_data *data, const 
struct cpumask *mask,
  
  int __irq_set_affinity(unsigned int irq, const struct cpumask *mask, bool force)

  {
-   struct irq_desc *desc = irq_to_desc(irq);
unsigned long flags;
+   struct irq_desc *desc = irq_get_desc_buslock(irq, ,
+   IRQ_GET_DESC_CHECK_GLOBAL);
int ret;
  
  	if (!desc)

return -EINVAL;
  
-	raw_spin_lock_irqsave(>lock, flags);

ret = irq_set_affinity_locked(irq_desc_get_irq_data(desc), mask, force);
-   raw_spin_unlock_irqrestore(>lock, flags);
+   irq_put_desc_busunlock(desc, flags);


I'd suggest that this just be an #idef'd implementation of the entire
__irq_set_affinity(). Make it selected by the board's top level Kconfig.

Bruce


return ret;
  }
  



--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 052/269] arch/arm: arm changes to support the axxia BSP

2018-03-21 Thread Bruce Ashfield 

On 03/02/2018 12:46 PM, Daniel Dragomir wrote:

From: Charlie Paul 

These files were changed to support the LSI axxia 5500 board.


I'm finally looking at these, sorry for the delay. See some
questions below.

I have questions, since this commit log has no details. :D




Signed-off-by: Charlie Paul 
Signed-off-by: John Jacques 
---
  arch/arm/Kconfig  | 84 ++-
  arch/arm/Kconfig.debug|  4 ++
  arch/arm/Makefile |  2 +-
  arch/arm/include/asm/kmap_types.h |  5 +++
  arch/arm/include/asm/spinlock.h   |  6 +++
  arch/arm/kernel/head.S|  8 
  arch/arm/kernel/irq.c |  2 +-
  arch/arm/kernel/perf_event_v7.c   |  3 +-
  arch/arm/tools/mach-types |  1 +
  9 files changed, 111 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c0fcab6..0f6c9e0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -359,6 +359,29 @@ config ARM_SINGLE_ARMV7M
select SPARSE_IRQ
select USE_OF
  
+config ARCH_AXXIA

+   bool "LSI Axxia family"
+   select ARCH_PHYS_ADDR_T_64BIT
+   select ARCH_DMA_ADDR_T_64BIT
+   select ARCH_WANT_OPTIONAL_GPIOLIB
+   select ARM_AMBA
+   select COMMON_CLK
+   select CLKDEV_LOOKUP
+   select CLKSRC_MMIO
+   select GENERIC_CLOCKEVENTS
+   select HAVE_CLK
+   select HAVE_PATA_PLATFORM
+   select ARM_TIMER_SP804
+   select ICST
+   select NEED_MACH_IO_H
+   select ZONE_DMA
+   select PCI
+   select PCI_DOMAINS if PCI
+   select ARCH_SUPPORTS_MSI if PCI
+   select HAS_RAPIDIO
+   help
+ This enables support for the LSI Axxia boards.
+
  config ARCH_EBSA110
bool "EBSA-110"
select ARCH_USES_GETTIMEOFFSET
@@ -839,6 +862,8 @@ source "arch/arm/mach-ux500/Kconfig"
  
  source "arch/arm/mach-versatile/Kconfig"
  
+source "arch/arm/mach-axxia/Kconfig"

+
  source "arch/arm/mach-vexpress/Kconfig"
  source "arch/arm/plat-versatile/Kconfig"
  
@@ -1268,6 +1293,19 @@ source "drivers/pci/Kconfig"
  
  source "drivers/pcmcia/Kconfig"
  
+config HAS_RAPIDIO

+   bool
+   default n
+
+config RAPIDIO
+   bool "RapidIO support"
+   depends on HAS_RAPIDIO || PCI


Shouldn't this be an "&&", not an "||" ? This is going to get
turned on for every config that has PCI, which from the HAS_RAPIDIO
doesn't look to be the intent.


+   help
+  If you say Y here, the kernel will include drivers and
+  infrastructure code to support RapidIO interconnect devices.
+
+source "drivers/rapidio/Kconfig"
+
  endmenu
  
  menu "Kernel Features"

@@ -1438,12 +1476,46 @@ config NR_CPUS
depends on SMP
default "4"
  
+menu "Support for hot-pluggable CPUs"

+
  config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
-   depends on SMP
+   depends on SMP && HOTPLUG


I don't see why this is being changed. Depending on SMP should
still be enough.


help
  Say Y here to experiment with turning CPUs off and on.  CPUs
  can be controlled through /sys/devices/system/cpu.
+choice
+   prompt "CPU Power Down Mode"
+   default HOTPLUG_CPU_COMPLETE_POWER_DOWN
+   help
+   This is used to select how the CPU is going to be powered down. 
If LOW POWER
+   is selected then the CPU enters a WFI state and waits for an 
interrupt to
+   wake up. If COMPLETE POWER down is selected the CPU power is 
turned off. The only
+   way to power on the CPU is to execute a command.
+
+config HOTPLUG_CPU_COMPLETE_POWER_DOWN
+   bool "Power off the CPU"
+   help
+   This will power off the CPU completely. The irqs are migrated
+   to another CPU.
+
+config HOTPLUG_CPU_LOW_POWER
+   bool "Low Power CPU (wfi)"
+   help
+   This will put the CPU into a low power mode wfi mode. When an 
interrupt
+   is received the CPU will power on again.
+
+endchoice
+
+config HOTPLUG_CPU_L2_POWER_DOWN
+   bool "Power Off L2 Cache"
+   depends on HOTPLUG_CPU_COMPLETE_POWER_DOWN
+   default n if HOTPLUG_CPU_LOW_POWER
+   help
+   Select this if you want to power down the L2 cache when
+   all CPUS of a cluster have been powered off.
+
+endmenu
  
  config ARM_PSCI

bool "Support for the ARM Power State Coordination Interface (PSCI)"
@@ -1456,6 +1528,16 @@ config ARM_PSCI
  0022A ("Power State Coordination Interface System Software on
  ARM processors").
  
+config LOCAL_TIMERS

+   bool "Use local timer interrupts"
+   depends on SMP
+   default y


A new option, should never be default 'y'. This should be default 'n'
and just add it to your config frags, or select it in the top level
board Kconfig.


+   help
+ Enable support for local timers on SMP

Re: [yocto] [PATCH 1/2] Do not skip packages that were attempted recently.

2018-03-21 Thread Alexander Kanavin 

On 03/21/2018 06:19 PM, Alexander Kanavin wrote:

This was undocumented and made a number of hardcoded assumptions.
The options were to make it configurable, or just remove the logic,
and I chose the latter.


Uh, forgot to add the [auh] prefix to these two.

Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/2] Do not skip packages that were attempted recently.

2018-03-21 Thread Alexander Kanavin 
This was undocumented and made a number of hardcoded assumptions.
The options were to make it configurable, or just remove the logic,
and I chose the latter.

Signed-off-by: Alexander Kanavin 
---
 upgradehelper.py | 40 
 1 file changed, 40 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index b5e696e..8fb27d3 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -564,17 +564,6 @@ class UniverseUpdater(Updater):
 E(" -t is only supported when upgrade one recipe\n")
 exit(1)
 
-# read history file
-self.history_file = os.path.join(get_build_dir(), "upgrade-helper", 
"history.uh")
-self.history = dict()
-if os.path.exists(self.history_file):
-with open(self.history_file) as history_file:
-for line in history_file:
-line = line.strip()
-self.history[line.split(',')[0]] = [line.split(',')[1],
-line.split(',')[2],
-line.split(',')[3],
-line.split(',')[4]]
 def _get_recipes_by_layer(self):
 recipes = []
 
@@ -689,21 +678,6 @@ class UniverseUpdater(Updater):
 (pn, maintainer))
 return False
 
-if pn in self.history:
-# did we already try this version?
-if next_ver == self.history[pn][0]:
-retry_delta = \
-date.toordinal(date.today()) - \
-date.toordinal(datetime.strptime(self.history[pn][2], 
'%Y-%m-%d'))
-# retry recipes that had fetch errors or other errors after
-# more than 30 days
-if (self.history[pn][3] == str(FetchError()) or
-self.history[pn][3] == str(Error())) and retry_delta > 
30:
-return True
-
-D(" Skipping upgrade of %s: is in history and not 30 days 
passed" % pn)
-return False
-
 # drop native/cross/cross-canadian recipes. We deal with native
 # when upgrading the main recipe but we keep away of cross* pkgs...
 # for now
@@ -727,22 +701,8 @@ class UniverseUpdater(Updater):
 
 return pkgs_list
 
-def _update_history(self, pn, new_ver, maintainer, upgrade_status):
-with open(self.history_file + ".tmp", "w+") as tmp_file:
-if os.path.exists(self.history_file):
-with open(self.history_file) as history:
-for line in history:
-if not line.startswith(pn):
-tmp_file.write(line)
-tmp_file.write(pn + "," + new_ver + "," + maintainer +
-   "," + date.isoformat(date.today()) + "," +
-   upgrade_status + "\n")
-os.rename(self.history_file + ".tmp", self.history_file)
-
 def pkg_upgrade_handler(self, pkg_ctx):
 super(UniverseUpdater, self).pkg_upgrade_handler(pkg_ctx)
-self._update_history(pkg_ctx['PN'], pkg_ctx['NPV'], 
pkg_ctx['MAINTAINER'],
-self._get_status_msg(pkg_ctx['error']))
 
 def run(self):
 self._prepare()
-- 
2.16.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 2/2] When 'devtool upgrade' fails to rebase patches, stop and report a failure

2018-03-21 Thread Alexander Kanavin 
Previously it would continue, which eventually resulted in an unhelpful, generic
error message printed by 'devtool finish'.

Signed-off-by: Alexander Kanavin 
---
 modules/steps.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/modules/steps.py b/modules/steps.py
index 5bbe38e..2eb4499 100644
--- a/modules/steps.py
+++ b/modules/steps.py
@@ -82,6 +82,10 @@ def devtool_upgrade(devtool, bb, git, opts, pkg_ctx):
 
 try:
 devtool_output = devtool.upgrade(pkg_ctx['PN'], pkg_ctx['NPV'], 
pkg_ctx['NSRCREV'])
+D(" 'devtool upgrade' printed:\n%s" %(devtool_output))
+# If devtool failed to rebase patches, it does not fail, but we should
+if 'conflict' in devtool_output:
+raise DevtoolError("Running 'devtool upgrade' for recipe %s 
failed." %(pkg_ctx['PN']), devtool_output)
 except DevtoolError as e1:
 try:
 devtool_output = devtool.reset(pkg_ctx['PN'])
@@ -96,7 +100,6 @@ def devtool_upgrade(devtool, bb, git, opts, pkg_ctx):
 with open(os.path.join(pkg_ctx['workdir'], 
pkg_ctx['license_diff_fn']), 'wb') as f:
 f.write(b"".join(license_diff_info))
 
-D(" 'devtool upgrade' printed:\n%s" %(devtool_output))
 
 def _compile(bb, pkg, machine, workdir):
 try:
-- 
2.16.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-security][rocko][PATCH] clamav: Add missing clamav.service file to SRC_URI

2018-03-21 Thread akuster 


On 03/20/2018 09:28 PM, Jagadeesh Krishnanjanappa wrote:
> Please ignore this patch, it gives an error as it is unable to
> inherit multilib-alternatives.This class is part of our internal layer.

This patch still has value. it addresses the systemd service file
installation.
- armin
>
> Regards,
> Jagadeesh
>
> On Tue, Mar 20, 2018 at 12:20 PM, Jagadeesh Krishnanjanappa
> > wrote:
>
> This solves the below error when systemd is used as init manager,
> -- snip --
> ERROR: clamav-0.99.2-r0 do_package: SYSTEMD_SERVICE_clamav value
> clamav.service does not exist
> ERROR: clamav-0.99.2-r0 do_package: Function failed:
> systemd_populate_packages
> -- snip --
>
> Other issues:
> 1. Ship /lib/systemd/system/clamav-freshclam.service into
> ${PN}-freshclam
>    package, to solve below warning:
> -- snip --
> [10240] WARNING: QA Issue: clamav: Files/directories were
> installed but not shipped in any package:
>   /lib/systemd/system/clamav-freshclam.service
> -- snip --
>
> 2. Solve rpm conflict error in do_populate_sdk, when clamav and
> mlib-clamav
>    are specified using IMAGE_INSTALL.
> -- snip --
> do_populate_sdk fails with below error:
>   file /usr/bin/clamav-config conflicts between attempted installs
> of lib32-clamav-dev-0.99.2-r0.i586 and clamav-dev-0.99.2-r0.corei7_64
> -- snip --
>
> Signed-off-by: Jagadeesh Krishnanjanappa
> >
> ---
>  recipes-security/clamav/clamav_0.99.2.bb
>  | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-security/clamav/clamav_0.99.2.bb
> 
> b/recipes-security/clamav/clamav_0.99.2.bb 
> index 5dfda8f..d7aa6d0 100644
> --- a/recipes-security/clamav/clamav_0.99.2.bb
> 
> +++ b/recipes-security/clamav/clamav_0.99.2.bb
> 
> @@ -14,6 +14,7 @@ SRC_URI =
> "git://github.com/vrtadmin/clamav-devel;branch=${PV}
>  \
>      file://clamd.conf \
>      file://freshclam.conf \
>      file://volatiles.03_clamav \
> +    file://${BPN}.service \
>      "
>
>  SRC_URI[md5sum] = "61b51a04619aeafd965892a53f86d192"
> @@ -26,7 +27,7 @@ SO_VER = "7.1.1"
>
>  EXTRANATIVEPATH += "chrpath-native"
>
> -inherit autotools-brokensep pkgconfig useradd systemd
> +inherit autotools-brokensep pkgconfig useradd systemd
> multilib-alternatives
>
>  UID = "clamav"
>  GID = "clamav"
> @@ -90,8 +91,13 @@ do_install_append() {
>      install -m 0644 ${WORKDIR}/volatiles.03_clamav 
> ${D}${sysconfdir}/default/volatiles/volatiles.03_clamav
>      sed -i -e 's#${STAGING_DIR_HOST}##g'
> ${D}${libdir}/pkgconfig/libclamav.pc
>      rm ${D}/${libdir}/libclamav.so
> +    if
> ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};then
> +       install -D -m 0644 ${WORKDIR}/clamav.service
> ${D}${systemd_unitdir}/system/clamav.service
> +    fi
>  }
>
> +MULTILIB_ALTERNATIVES_${PN}-dev = "${bindir}/clamav-config"
> +
>  pkg_postinst_${PN} () {
>      if [ -z "$D" ] && [ -e /etc/init.d/populate-volatile.sh ] ; then
>          ${sysconfdir}/init.d/populate-volatile.sh update
> @@ -126,7 +132,8 @@ FILES_${PN}-freshclam = "${bindir}/freshclam \
>                          ${sysconfdir}/clamav
> ${sysconfdir}/default/volatiles \
>                          ${localstatedir}/lib/clamav \
>                          ${docdir}/${PN}-freshclam
> ${mandir}/man1/freshclam.* \
> -                        ${mandir}/man5/freshclam.conf.*"
> +                        ${mandir}/man5/freshclam.conf.* \
> +                       
> ${systemd_unitdir}/system/clamav-freshclam.service"
>
>  FILES_${PN}-dev = " ${bindir}/clamav-config ${libdir}/*.la \
>                      ${libdir}/pkgconfig/*.pc \
> --
> 2.7.4
>
>
>
>

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [RFC] Priority Settings Between Layers

2018-03-21 Thread Stephano Cetola 
We're updating our manuals and I want to be sure the information we are
providing is correct. Here is the section in question:


TIP
Ordering and BBFILE_PRIORITY for the layers listed in BBLAYERS matter.
For example, if multiple layers define a machine configuration, the
OpenEmbedded build system uses the last layer searched given similar
layer priorities. The build system works from the top-down through the
layers listed in BBLAYERS.


Is this accurate? I have tested this with a simple machine config
example but I want to be sure I am not missing anything. Also, I'm
assuming this holds true for all configurations, not just machine.

Cheers,
Stephano
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building BlueZ from git in Yocto

2018-03-21 Thread Alexander Kanavin 

On 03/21/2018 05:47 PM, Alan Martinovic wrote:

When you say "tagged as backports" are you referring to the Upstream-Status?

So this is a backport patch:
 Upstream-Status: Accepted
[https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=76255f73
2d68aef2b90d36d9c7be51a9e1739ce7]

but these two aren't yet or never will be:
 Upstream-Status: Submitted
 Upstream-Status: Denied


See here for explanations:
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations:_Upstream-Status

In either case, do not rely on Upstream-Status when deciding what to 
drop and what to keep. The only authority is actual code: if it already 
contains the patch (or, in rare cases, resolves the issue in a different 
way), you can drop it. Otherwise you most likely need to keep it, 
rebasing as needed.


Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building BlueZ from git in Yocto

2018-03-21 Thread Alan Martinovic 
When you say "tagged as backports" are you referring to the Upstream-Status?

So this is a backport patch:
Upstream-Status: Accepted
[https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=76255f73
   2d68aef2b90d36d9c7be51a9e1739ce7]

but these two aren't yet or never will be:
Upstream-Status: Submitted
Upstream-Status: Denied

On Wed, Mar 21, 2018 at 4:39 PM, Burton, Ross  wrote:
> If you look at the patch headers, you'll see that none of them are
> tagged as backports.
>
> Ross
>
> On 21 March 2018 at 15:35, Alan Martinovic  wrote:
>> Hey Ross, thanks for the clarification.
>>
>> The issues reoccurred because I modified the recipe not to include any 
>> patches,
>> falsely assuming that all of them were BlueZ backports and none is actually
>> a Yocto specific change.
>>
>> On Wed, Mar 21, 2018 at 4:23 PM, Burton, Ross  wrote:
>>> On 21 March 2018 at 15:15, Alan Martinovic 
>>> wrote:


 Building it with Yocto results in the mentioned error:

 | ../git/src/genbuiltin hostname wiimote autopair policy   a2dp avrcp
 network input hog  gap scanparam deviceinfo  battery > src/builtin.h
 | ../git/obexd/src/genbuiltin filesystem bluetooth  opp ftp irmc pbap mas
 mns > obexd/src/builtin.h
 | /bin/bash: obexd/src/builtin.h: No such file or directory
 | Makefile:9431: recipe for target 'obexd/src/builtin.h' failed
 | make: *** [obexd/src/builtin.h] Error 1
 | make: *** Waiting for unfinished jobs
 | ERROR: oe_runmake failed
 | WARNING: exit code 1 from a shell command.


 It seems that for some reason in Yocto, make can't redirect into
 `obexd/src/builtin.h` while
 it does so successfully for native build.
>>>
>>>
>>> Yocto will be doing an out-of-tree build with high parallelism, neither of
>>> which you are likely doing yourself.
>>>
>>> The hint is "no such file or directory" for a file it is writing *to*.  This
>>> means the parent doesn't exist, in this case obexd/src/.
>>>
>>> This is a typical race in out-of-tree and parallel builds, where genbuiltin
>>> is racing against other commands to create the directory.  The fix is to
>>> ensure that whatever rule calls genbuiltin actually does a mkdir first.
>>>
>>> We have a fix for this already in oe-core:
>>>
>>> http://git.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/bluez5/bluez5/out-of-tree.patch
>>>
>>> So I imagine you're using an old release of Yocto.  I sent this patch to the
>>> linux-bluetooth list in April 2016 but it was either moderated away or
>>> missed.
>>>
>>> Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building BlueZ from git in Yocto

2018-03-21 Thread Burton, Ross 
If you look at the patch headers, you'll see that none of them are
tagged as backports.

Ross

On 21 March 2018 at 15:35, Alan Martinovic  wrote:
> Hey Ross, thanks for the clarification.
>
> The issues reoccurred because I modified the recipe not to include any 
> patches,
> falsely assuming that all of them were BlueZ backports and none is actually
> a Yocto specific change.
>
> On Wed, Mar 21, 2018 at 4:23 PM, Burton, Ross  wrote:
>> On 21 March 2018 at 15:15, Alan Martinovic 
>> wrote:
>>>
>>>
>>> Building it with Yocto results in the mentioned error:
>>>
>>> | ../git/src/genbuiltin hostname wiimote autopair policy   a2dp avrcp
>>> network input hog  gap scanparam deviceinfo  battery > src/builtin.h
>>> | ../git/obexd/src/genbuiltin filesystem bluetooth  opp ftp irmc pbap mas
>>> mns > obexd/src/builtin.h
>>> | /bin/bash: obexd/src/builtin.h: No such file or directory
>>> | Makefile:9431: recipe for target 'obexd/src/builtin.h' failed
>>> | make: *** [obexd/src/builtin.h] Error 1
>>> | make: *** Waiting for unfinished jobs
>>> | ERROR: oe_runmake failed
>>> | WARNING: exit code 1 from a shell command.
>>>
>>>
>>> It seems that for some reason in Yocto, make can't redirect into
>>> `obexd/src/builtin.h` while
>>> it does so successfully for native build.
>>
>>
>> Yocto will be doing an out-of-tree build with high parallelism, neither of
>> which you are likely doing yourself.
>>
>> The hint is "no such file or directory" for a file it is writing *to*.  This
>> means the parent doesn't exist, in this case obexd/src/.
>>
>> This is a typical race in out-of-tree and parallel builds, where genbuiltin
>> is racing against other commands to create the directory.  The fix is to
>> ensure that whatever rule calls genbuiltin actually does a mkdir first.
>>
>> We have a fix for this already in oe-core:
>>
>> http://git.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/bluez5/bluez5/out-of-tree.patch
>>
>> So I imagine you're using an old release of Yocto.  I sent this patch to the
>> linux-bluetooth list in April 2016 but it was either moderated away or
>> missed.
>>
>> Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building BlueZ from git in Yocto

2018-03-21 Thread Alan Martinovic 
Hey Ross, thanks for the clarification.

The issues reoccurred because I modified the recipe not to include any patches,
falsely assuming that all of them were BlueZ backports and none is actually
a Yocto specific change.

On Wed, Mar 21, 2018 at 4:23 PM, Burton, Ross  wrote:
> On 21 March 2018 at 15:15, Alan Martinovic 
> wrote:
>>
>>
>> Building it with Yocto results in the mentioned error:
>>
>> | ../git/src/genbuiltin hostname wiimote autopair policy   a2dp avrcp
>> network input hog  gap scanparam deviceinfo  battery > src/builtin.h
>> | ../git/obexd/src/genbuiltin filesystem bluetooth  opp ftp irmc pbap mas
>> mns > obexd/src/builtin.h
>> | /bin/bash: obexd/src/builtin.h: No such file or directory
>> | Makefile:9431: recipe for target 'obexd/src/builtin.h' failed
>> | make: *** [obexd/src/builtin.h] Error 1
>> | make: *** Waiting for unfinished jobs
>> | ERROR: oe_runmake failed
>> | WARNING: exit code 1 from a shell command.
>>
>>
>> It seems that for some reason in Yocto, make can't redirect into
>> `obexd/src/builtin.h` while
>> it does so successfully for native build.
>
>
> Yocto will be doing an out-of-tree build with high parallelism, neither of
> which you are likely doing yourself.
>
> The hint is "no such file or directory" for a file it is writing *to*.  This
> means the parent doesn't exist, in this case obexd/src/.
>
> This is a typical race in out-of-tree and parallel builds, where genbuiltin
> is racing against other commands to create the directory.  The fix is to
> ensure that whatever rule calls genbuiltin actually does a mkdir first.
>
> We have a fix for this already in oe-core:
>
> http://git.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/bluez5/bluez5/out-of-tree.patch
>
> So I imagine you're using an old release of Yocto.  I sent this patch to the
> linux-bluetooth list in April 2016 but it was either moderated away or
> missed.
>
> Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto and NPM issues

2018-03-21 Thread Alexander Kanavin 

On 03/21/2018 04:44 PM, Svein Seldal wrote:


 > Oh, and you might have more success using meta-nodejs, as it doesn't try
 > to implement a custom fetcher, and just runs npm directly during the
 > build. If you don't mind that that makes the build outcome essentially
 > random from one invocation to the next.
 >
 > https://github.com/imyller/meta-nodejs

The meta-nodejs repo seems to be abandoned, as it does support any newer 
versions of nodejs. I asked on #yocto and I was suggested that this 
layer wasn't really necessary as meta-openembedded supports nodejs.


You have seen first-hand what 'supports' means in practice :-) As long 
as it's not regularly, automatically tested against a wide set of target 
npm packages, it just isn't going to work well.


I'd suggest you could take over the maintenance of meta-nodejs maybe?

Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building BlueZ master from git in Yocto

2018-03-21 Thread Burton, Ross 
Just noticed this:

On 21 March 2018 at 15:21, Alan Martinovic 
wrote:

> Before hand did all the steps so that BlueZ is correctly pulled
> from master, and no patches from Yocto are applied to it.
>

You've removed our fixes for the bugs in bluez5.  Add them back. :)

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building BlueZ from git in Yocto

2018-03-21 Thread Burton, Ross 
On 21 March 2018 at 15:15, Alan Martinovic 
wrote:

>
> Building it with Yocto results in the mentioned error:
>
> | ../git/src/genbuiltin hostname wiimote autopair policy   a2dp avrcp
> network input hog  gap scanparam deviceinfo  battery > src/builtin.h
> | ../git/obexd/src/genbuiltin filesystem bluetooth  opp ftp irmc pbap mas
> mns > obexd/src/builtin.h
> | /bin/bash: obexd/src/builtin.h: No such file or directory
> | Makefile:9431: recipe for target 'obexd/src/builtin.h' failed
> | make: *** [obexd/src/builtin.h] Error 1
> | make: *** Waiting for unfinished jobs
> | ERROR: oe_runmake failed
> | WARNING: exit code 1 from a shell command.
>
>
> It seems that for some reason in Yocto, make can't redirect into
> `obexd/src/builtin.h` while
> it does so successfully for native build.
>

Yocto will be doing an out-of-tree build with high parallelism, neither of
which you are likely doing yourself.

The hint is "no such file or directory" for a file it is writing *to*.
This means the parent doesn't exist, in this case obexd/src/.

This is a typical race in out-of-tree and parallel builds, where genbuiltin
is racing against other commands to create the directory.  The fix is to
ensure that whatever rule calls genbuiltin actually does a mkdir first.

We have a fix for this already in oe-core:

http://git.openembedded.org/openembedded-core/tree/meta/
recipes-connectivity/bluez5/bluez5/out-of-tree.patch

So I imagine you're using an old release of Yocto.  I sent this patch to
the linux-bluetooth list in April 2016 but it was either moderated away or
missed.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Building BlueZ master from git in Yocto

2018-03-21 Thread Alan Martinovic 
Started this issue a few days ago thinking it was a problem with
the bluez flags. I guess it might still be given it tries to build obex
even when it's been configured that is shouldn't...

The exact issue seems to point it's a Yocto related
or might be both (hence both lists). I have configured
BlueZ to build without any flags.

In terms of BlueZ code this means:

git clone https://git.kernel.org/pub/scm/bluetooth/bluez.git
cd bluez
./bootstrap
make

This is built correctly for x86.

Trying to replicate that to Yocto, I've extended the recipe to
not to pass any feature configuration flags:

$ bitbake bluez5 -e | grep EXTRA_OECONF
...
EXTRA_OECONF=""

Before hand did all the steps so that BlueZ is correctly pulled
from master, and no patches from Yocto are applied to it.

Building it with Yocto results in the mentioned error:

| ../git/src/genbuiltin hostname wiimote autopair policy   a2dp avrcp
network input hog  gap scanparam deviceinfo  battery > src/builtin.h
| ../git/obexd/src/genbuiltin filesystem bluetooth  opp ftp irmc pbap
mas mns > obexd/src/builtin.h
| /bin/bash: obexd/src/builtin.h: No such file or directory
| Makefile:9431: recipe for target 'obexd/src/builtin.h' failed
| make: *** [obexd/src/builtin.h] Error 1
| make: *** Waiting for unfinished jobs
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.


It seems that for some reason in Yocto, make can't redirect into
`obexd/src/builtin.h` while
it does so successfully for native build.

Open for comments/critics on how to diagnose this :)

Be Well,
Alan





On Fri, Mar 16, 2018 at 5:13 PM, Luiz Augusto von Dentz
 wrote:
>
> Hi Alan,
>
> On Fri, Mar 16, 2018 at 4:50 PM, Alan Martinovic
>  wrote:
> > Hi,
> > I'm trying to cross compile a BLE BlueZ master.
> > Am having build issues pointing to obex.
> > I'm building it using Yocto but have stripped it down
> > to the essentials:
> >
> > ./configure
> >   --build=x86_64-linux
> >   --host=arm-linux-gnueabi
> >   --target=arm-linux-gnueabi
> >   --prefix=/usr
> >   --exec_prefix=/usr
> >   --bindir=/usr/bin
> >   --sbindir=/usr/sbin
> >   --libexecdir=/usr/libexec
> >   --datadir=/usr/share
> >   --sysconfdir=/etc
> >   --sharedstatedir=/com
> >   --localstatedir=/var
> >   --libdir=/usr/lib
> >   --includedir=/usr/include
> >   --oldincludedir=/usr/include
> >   --infodir=/usr/share/info
> >   --mandir=/usr/share/man
> >   --disable-silent-rules
> >   --disable-dependency-tracking
> >   
> > --with-libtool-sysroot=/home/alan/senic-os/build/tmp-glibc/work/cortexa7hf-neon-vfpv4-senic-linux-gnueabi/bluez5/5.49+gitAUTOINC+969dfae9a7-r0/recipe-sysroot
> >   --enable-test
> >   --enable-datafiles
> >   --enable-library
> >   --enable-a2dp
> >   --enable-avrcp
> >   --disable-cups
> >   --enable-deprecated
> >   --disable-health
> >   --enable-hid
> >   --enable-hog
> >   --disable-midi
> >   --enable-network
> >   --disable-nfc
> >   --disable-obex
> >   --enable-client
> >   --disable-sap
> >   --disable-sixaxis
> >   --enable-systemd
> >   --disable-testing
> >   --disable-threads
> >   --enable-tools
> > make -j 16
> >
> > This results in a build error:
> >
> >  ../git/obexd/src/genbuiltin filesystem bluetooth  opp ftp  mas mns >
> > obexd/src/builtin.h
> >  /bin/bash: obexd/src/builtin.h: No such file or directory
> >  Makefile:9431: recipe for target 'obexd/src/builtin.h' failed
> >
> >
> > Given that I don't need it for BLE, what else is required
> > besides "--disable-obex" to bypass this error?
>
> Obviously, it is a bug in the way we handle --disable-obex so we will
> need to fix it.
>
> --
> Luiz Augusto von Dentz
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Building BlueZ from git in Yocto

2018-03-21 Thread Alan Martinovic 
Started this issue a few days ago thinking it was a problem with
the bluez flags. I guess it might still be given it tries to build obex
even when it's been configured that is shouldn't...

The exact issue seems to point it's a Yocto related
or might be both (hence both lists). I have configured
BlueZ to build without any flags.

In terms of BlueZ code this means:

git clone https://git.kernel.org/pub/scm/bluetooth/bluez.git
cd bluez
./bootstrap
make

This is built correctly for x86.

Trying to replicate that to Yocto, I've extended the recipe to
not to pass any feature configuration flags:

$ bitbake bluez5 -e | grep EXTRA_OECONF
...
EXTRA_OECONF=""

Before hand did all the steps so that BlueZ is correctly pulled
from master, and no patches from Yocto are applied to it.

Building it with Yocto results in the mentioned error:

| ../git/src/genbuiltin hostname wiimote autopair policy   a2dp avrcp
network input hog  gap scanparam deviceinfo  battery > src/builtin.h
| ../git/obexd/src/genbuiltin filesystem bluetooth  opp ftp irmc pbap mas
mns > obexd/src/builtin.h
| /bin/bash: obexd/src/builtin.h: No such file or directory
| Makefile:9431: recipe for target 'obexd/src/builtin.h' failed
| make: *** [obexd/src/builtin.h] Error 1
| make: *** Waiting for unfinished jobs
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.


It seems that for some reason in Yocto, make can't redirect into
`obexd/src/builtin.h` while
it does so successfully for native build.

Open for comments/critics on how to diagnose this :)

Be Well,
Alan





On Fri, Mar 16, 2018 at 5:13 PM, Luiz Augusto von Dentz <
luiz.de...@gmail.com> wrote:

> Hi Alan,
>
> On Fri, Mar 16, 2018 at 4:50 PM, Alan Martinovic
>  wrote:
> > Hi,
> > I'm trying to cross compile a BLE BlueZ master.
> > Am having build issues pointing to obex.
> > I'm building it using Yocto but have stripped it down
> > to the essentials:
> >
> > ./configure
> >   --build=x86_64-linux
> >   --host=arm-linux-gnueabi
> >   --target=arm-linux-gnueabi
> >   --prefix=/usr
> >   --exec_prefix=/usr
> >   --bindir=/usr/bin
> >   --sbindir=/usr/sbin
> >   --libexecdir=/usr/libexec
> >   --datadir=/usr/share
> >   --sysconfdir=/etc
> >   --sharedstatedir=/com
> >   --localstatedir=/var
> >   --libdir=/usr/lib
> >   --includedir=/usr/include
> >   --oldincludedir=/usr/include
> >   --infodir=/usr/share/info
> >   --mandir=/usr/share/man
> >   --disable-silent-rules
> >   --disable-dependency-tracking
> >   --with-libtool-sysroot=/home/alan/senic-os/build/tmp-glibc/
> work/cortexa7hf-neon-vfpv4-senic-linux-gnueabi/bluez5/5.
> 49+gitAUTOINC+969dfae9a7-r0/recipe-sysroot
> >   --enable-test
> >   --enable-datafiles
> >   --enable-library
> >   --enable-a2dp
> >   --enable-avrcp
> >   --disable-cups
> >   --enable-deprecated
> >   --disable-health
> >   --enable-hid
> >   --enable-hog
> >   --disable-midi
> >   --enable-network
> >   --disable-nfc
> >   --disable-obex
> >   --enable-client
> >   --disable-sap
> >   --disable-sixaxis
> >   --enable-systemd
> >   --disable-testing
> >   --disable-threads
> >   --enable-tools
> > make -j 16
> >
> > This results in a build error:
> >
> >  ../git/obexd/src/genbuiltin filesystem bluetooth  opp ftp  mas mns >
> > obexd/src/builtin.h
> >  /bin/bash: obexd/src/builtin.h: No such file or directory
> >  Makefile:9431: recipe for target 'obexd/src/builtin.h' failed
> >
> >
> > Given that I don't need it for BLE, what else is required
> > besides "--disable-obex" to bypass this error?
>
> Obviously, it is a bug in the way we handle --disable-obex so we will
> need to fix it.
>
> --
> Luiz Augusto von Dentz
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto and NPM issues

2018-03-21 Thread Svein Seldal 


On 21.03.2018 14:54, Alexander Kanavin wrote:
I'm attempting to package a npm-based js application into a Rocko 
image, and I'm having some issues. For testing I use the official poky 
repo and the meta-openembedded repo (for installing nodejs 8.4.0). I'm 
building for qemux86-64.


I know this is not an answer to your specific issues, but npm is a bit 
of maintenance nightmare as its workflow (downloading random stuff off 
the internet as an integral part of the build) clashes badly with how 
bitbake, and embedded world in general handle builds. We've discussed 
what to do about it, with no clear outcome, but we would like to have 
something that doesn't require constant fixing and hacks:


http://lists.openembedded.org/pipermail/openembedded-architecture/2017-March/000480.html 


I haven't read the post in full yet, but the principle of npm is 
inherently different from the philosophies of Yocto, granted.


One approach that we've been discussing as an alternative to the 
yocto+npm approach is to install the js app on a target machine and 
snapshot the whole resulting directory hierarchy. The product validation 
is then made on the modules as a whole. The recipe would need to be a 
simple file-installer.


The problem with that is that one needs a target deployment system that 
runs npm install on the actual target in order to make the correct files 
for the target. The output from that must be plugged into the oe build 
system somehow, so there will be many moving parts in this scheme too.


> Oh, and you might have more success using meta-nodejs, as it doesn't try
> to implement a custom fetcher, and just runs npm directly during the
> build. If you don't mind that that makes the build outcome essentially
> random from one invocation to the next.
>
> https://github.com/imyller/meta-nodejs

The meta-nodejs repo seems to be abandoned, as it does support any newer 
versions of nodejs. I asked on #yocto and I was suggested that this 
layer wasn't really necessary as meta-openembedded supports nodejs.



Best regards,
Svein
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Yocto Project Status WW12’18

2018-03-21 Thread Burton, Ross 
Monthly seems like a good enough cadence to give everyone time to review
the mails, send the mails, get reviewed on the list, go through the
autobuilder, and eventually reach master.  Too fast and AUH will be sending
nagging mails for a patch which is shortly being merged.

Can we stop bikeshedding now? :)

Ross

On 21 March 2018 at 14:31, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 03/21/2018 04:24 PM, Philip Balister wrote:
>
>>  Which brings me to a question: what is a good schedule and cadence
  for AUH runs? Currently it's run on the 15th of every odd-numbered
  month (so January, March, and so on), but I thought of shifting it
  one month forward, so it doesn't land right in the middle of a
  feature freeze. Thoughts?


 How long does a single run take, and why not run it every month?

>>>
>>> Just a bit longer than a day, maybe 30 hours, if it needs to update the
>>> typical amount of 100-150 packages. I'll shift it to monthly then.
>>>
>>
>> Maybe bi-weekly? Could that help reduce the number of upgrades needed
>> for each run?
>>
>
> Only if the maintainers take those reminders as high priority items, and
> actually send out the patches quickly, and then those patches make it to
> master. All that needs to happen within those two weeks. Otherwise, the AUH
> will just re-run the same set.
>
> Alex
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Does PACKAGECONFIG only apply to autotools recipes

2018-03-21 Thread Burton, Ross 
On 21 March 2018 at 13:34, Alan Martinovic 
wrote:

> Thanks. :)
> I guess it's safe to say that it has a confined usage to recipes that
> require
> configuration before the compilation process.
>
> Like a source written in c using autotools as the build system for which
> you
> pass configure flags and would potentially need to pass library paths...
> As opposed to a python recipe that doesn't need to be build.
>

Just to be that person who says "well, actually"...

The piglit recipe uses PACKAGECONFIG and that is pure Python.  You can
still have a configure phase with Python code.

Any recipe is welcome to use the PACKAGECONFIG variable, it just has to
respect PACKAGECONFIG_CONFARGS which apart from a few recipes with entirely
home-grown build systems is done in the classes.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Yocto Project Status WW12’18

2018-03-21 Thread Philip Balister 
On 03/20/2018 05:26 AM, Alexander Kanavin wrote:
> On 03/20/2018 12:52 PM, Burton, Ross wrote:
>>     Which brings me to a question: what is a good schedule and cadence
>>     for AUH runs? Currently it's run on the 15th of every odd-numbered
>>     month (so January, March, and so on), but I thought of shifting it
>>     one month forward, so it doesn't land right in the middle of a
>>     feature freeze. Thoughts?
>>
>>
>> How long does a single run take, and why not run it every month?
> 
> Just a bit longer than a day, maybe 30 hours, if it needs to update the
> typical amount of 100-150 packages. I'll shift it to monthly then.

Maybe bi-weekly? Could that help reduce the number of upgrades needed
for each run?

Philip
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto and NPM issues

2018-03-21 Thread Alexander Kanavin 

On 03/21/2018 03:54 PM, Alexander Kanavin wrote:

I'm attempting to package a npm-based js application into a Rocko 
image, and I'm having some issues. For testing I use the official poky 
repo and the meta-openembedded repo (for installing nodejs 8.4.0). I'm 
building for qemux86-64.


I know this is not an answer to your specific issues, but npm is a bit 
of maintenance nightmare as its workflow (downloading random stuff off 
the internet as an integral part of the build) clashes badly with how 
bitbake, and embedded world in general handle builds. We've discussed 
what to do about it, with no clear outcome, but we would like to have 
something that doesn't require constant fixing and hacks:


http://lists.openembedded.org/pipermail/openembedded-architecture/2017-March/000480.html 


Oh, and you might have more success using meta-nodejs, as it doesn't try 
to implement a custom fetcher, and just runs npm directly during the 
build. If you don't mind that that makes the build outcome essentially 
random from one invocation to the next.


https://github.com/imyller/meta-nodejs


Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto and NPM issues

2018-03-21 Thread Alexander Kanavin 

On 03/21/2018 03:09 PM, Svein Seldal wrote:

Hi

I'm attempting to package a npm-based js application into a Rocko image, 
and I'm having some issues. For testing I use the official poky repo and 
the meta-openembedded repo (for installing nodejs 8.4.0). I'm building 
for qemux86-64.


I know this is not an answer to your specific issues, but npm is a bit 
of maintenance nightmare as its workflow (downloading random stuff off 
the internet as an integral part of the build) clashes badly with how 
bitbake, and embedded world in general handle builds. We've discussed 
what to do about it, with no clear outcome, but we would like to have 
something that doesn't require constant fixing and hacks:


http://lists.openembedded.org/pipermail/openembedded-architecture/2017-March/000480.html


Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto and NPM issues

2018-03-21 Thread Svein Seldal 

Hi

I'm attempting to package a npm-based js application into a Rocko image, 
and I'm having some issues. For testing I use the official poky repo and 
the meta-openembedded repo (for installing nodejs 8.4.0). I'm building 
for qemux86-64.



Issue 1: NPM builds not working in Rocko

If I'm following the examples outlined in 
https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM, and run devtool 
add "npm://registry.npmjs.org;name=cute-files;version=1.0.2" and then 
bitbake cute-file. It fails on an npm error seen below. I found that 
this patch fixes the problem: 
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/classes/npm.bbclass?id=d38e1e2c2ea4646b34ea6282d3d7620df5b0374b


Will there be more releases of rocko? Can I request that this patch is 
backported to the rocko branch please?



Issue 2: Workspace npm recipe does not work after bitbake -c cleanall

If using the devtool/workspace for the above recipe, and run bitbake -c 
cleanall cute-files, then try to rerun bitbake cute-files, it will warn 
on missing LICENSE files for the npm packages and fail on 
LIC_FILES_CHKSUM point to an invalid file QA error. E.g. something in 
line of:


WARNING: cute-files-1.0.2-r0 do_populate_lic: Could not copy license 
file 
/home/common/yocto/yocto-poky/build/workspace/sources/cute-files/node_modules/express/node_modules/serve-static/node_modules/send/node_modules/ms/license.md 
to 
/home/common/yocto/yocto-poky/build/tmp/work/core2-64-poky-linux/cute-files/1.0.2-r0/license-destdir/cute-files/license.md: 
[Errno 2] No such file or directory: 
'/home/common/yocto/yocto-poky/build/workspace/sources/cute-files/node_modules/express/node_modules/serve-static/node_modules/send/node_modules/ms/license.md'
ERROR: cute-files-1.0.2-r0 do_populate_lic: QA Issue: cute-files: 
LIC_FILES_CHKSUM points to an invalid file: 
/home/common/yocto/yocto-poky/build/workspace/sources/cute-files/node_modules/express/node_modules/accepts/LICENSE 
[license-checksum]



Issue 3: npm recipe fails to download npm images after -c cleanall

If the recipe is copied into a normal layer and run without externalsrc, 
and runned after a -c cleanall, the following error is returned:


WARNING: cute-files-1.0.2-r0 do_fetch: Checksum failure encountered with 
download of npm://registry.npmjs.org;name=cute-files;version=1.0.2 - 
will attempt other sources if available

ERROR: cute-files-1.0.2-r0 do_fetch: Fetcher failure: Checksum mismatch!
File: 'commander-2.15.1.tgz' has sha1 checksum 
df46e867d0fc2aec66a34662b406a9ccafff5b0f when * was expected
ERROR: cute-files-1.0.2-r0 do_fetch: Fetcher failure for URL: 
'npm://registry.npmjs.org;name=cute-files;version=1.0.2'. Unable to 
fetch URL from any source.

ERROR: cute-files-1.0.2-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: 
/home/common/yocto/yocto-poky/build/tmp/work/core2-64-poky-linux/cute-files/1.0.2-r0/temp/log.do_fetch.20513
ERROR: Task 
(/home/common/yocto/yocto-poky/meta-foobar/recipes/cute-files/cute-files_1.0.2.bb:do_fetch) 
failed with exit code '1'



The only way to circumvent issue 2 and 3 after a -c cleanall is to use 
the devtool to download the packages, and then build the package as 
normal.



Best regards,
Svein




FAILURE Building cute-files:

ERROR: cute-files-1.0.2-r0 do_compile: Function failed: do_compile (log 
file is located at 
/home/common/yocto/yocto-poky/build/tmp/work/core2-64-poky-linux/cute-files/1.0.2-r0/temp/log.do_compile.9536)
ERROR: Logfile of failure stored in: 
/home/common/yocto/yocto-poky/build/tmp/work/core2-64-poky-linux/cute-files/1.0.2-r0/temp/log.do_compile.9536

Log data follows:
| DEBUG: Executing python function externalsrc_compile_prefunc
| NOTE: cute-files: compiling from external source tree 
/home/common/yocto/yocto-poky/build/workspace/sources/cute-files

| DEBUG: Python function externalsrc_compile_prefunc finished
| DEBUG: Executing shell function do_compile
| npm ERR! As of npm@5, the npm cache self-heals from corruption issues 
and data extracted from the cache is guaranteed to be valid. If you want 
to make sure everything is consistent, use 'npm cache verify' instead.

| npm ERR!
| npm ERR! If you're sure you want to delete the entire cache, rerun 
this command with --force.

|
| npm ERR! A complete log of this run can be found in:
| npm ERR! 
/home/common/yocto/yocto-poky/build/tmp/work/core2-64-poky-linux/cute-files/1.0.2-r0/npm_cache/_logs/2018-03-21T12_36_48_034Z-debug.log

| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at 
/home/common/yocto/yocto-poky/build/tmp/work/core2-64-poky-linux/cute-files/1.0.2-r0/temp/log.do_compile.9536)
ERROR: Task 
(/home/common/yocto/yocto-poky/build/workspace/recipes/cute-files/cute-files_1.0.2.bb:do_compile) 
failed with exit code '1'

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Does PACKAGECONFIG only apply to autotools recipes

2018-03-21 Thread Alan Martinovic 
Thanks. :)
I guess it's safe to say that it has a confined usage to recipes that
require
configuration before the compilation process.

Like a source written in c using autotools as the build system for which
you
pass configure flags and would potentially need to pass library paths...
As opposed to a python recipe that doesn't need to be build.



On Thu, Mar 15, 2018 at 6:31 PM, Martin Jansa 
wrote:

> It's applied in PACKAGECONFIG_CONFARGS variable and various bbclasses (and
> also various recipes) use this variable where needed, see git grep:
>
> meta/classes/base.bbclass:appendVar('PACKAGECONFIG_CONFARGS',
> extraconf)
>
> meta/classes/autotools.bbclass:EXTRA_OECONF_append = "
> ${PACKAGECONFIG_CONFARGS}"
> meta/classes/cmake.bbclass:EXTRA_OECMAKE_append = "
> ${PACKAGECONFIG_CONFARGS}"
> meta/classes/meson.bbclass:EXTRA_OEMESON += "${PACKAGECONFIG_CONFARGS}"
> meta/classes/waf.bbclass:EXTRA_OECONF_append = "
> ${PACKAGECONFIG_CONFARGS}"
>
> meta/recipes-graphics/glew/glew_2.1.0.bb:EXTRA_OEMAKE =
> "${PACKAGECONFIG_CONFARGS} \
>
> It used to be included in EXTRA_OECONF by default, before:
> http://git.openembedded.org/openembedded-core/commit/?id=
> c98fb5f5129e71829ffab4449b3d28082bc95ab4
>
> On Thu, Mar 15, 2018 at 6:22 PM, Alan Martinovic <
> alan.martino...@senic.com> wrote:
>
>> Hi,
>> is it true that that PACKAGECONFIG is only used
>>  for recipes that inherit autoconf?
>>
>> Was trying to understand what they do in a recipe:
>> https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipe
>> s-connectivity/bluez5/bluez5.inc
>> and didn't really get what this was about until found
>> the autoconf reference mentioned in a book.
>>
>> So "features" as referenced in the mega manual:
>> https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manua
>> l.html#var-PACKAGECONFIG
>> are the flags that will end up being passed to ./configure?
>>
>> However later in the recipe it's used to populate other variables
>>
>> NOINST_TOOLS = " \
>> ${@bb.utils.contains('PACKAGECONFIG', 'readline',
>> '${NOINST_TOOLS_READLINE}', '', d)} \
>> ${@bb.utils.contains('PACKAGECONFIG', 'testing',
>> '${NOINST_TOOLS_TESTING}', '', d)} \
>> ${@bb.utils.contains('PACKAGECONFIG', 'tools',
>> '${NOINST_TOOLS_BT}', '', d)} \
>> "
>>
>> Is the original assumption true (that it's an autoconf only thing)?
>> Is there a way to test that by grepping the code (didn't found
>> autoconf references when greping for PACKAGECONFIG in
>> bitbake -e bluez5)?
>>
>> Be Well :)
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Release candidate build for Yocto Project 2.5 M3 rc1

2018-03-21 Thread Richard Purdie 
Hi,

We have a build ready for QA for the Yocto Project release 2.5 M3 rc1.
This build is slightly different in that it has been run on the new
autobuilder codebase. We don't have automated release emails yet so I'm
writing this manually. The release is available at:

http://autobuilder.yoctoproject.org/pub/yocto-2.5_M3.rc1/

The build results can be seen at:

https://autobuilder.yoctoproject.org/new/#/console

As you can see, there was one failure in nightly-qa-extras to do with
syslogd under systemd images. Right now I think we note this for the M3
release and fix during M4, it was caused by the systemd upgrade which
was added late on. We will need a bug for this.

For comparison, I also built this release on the current yocto.io
infrastructure. I have an additional request for QA to compare the list
of artefacts generated from the new codebase with the artefacts from
the old codebase. Those are available here:

https://autobuilder.yocto.io/pub/releases/yocto-2.5_M3.rc1/
(from https://autobuilder.yocto.io/builders/nightly/builds/965 which
had the same qa-extras failure).

I did already notice we're missing the top level tarballs , which is
odd since I know we do generate them. This is something we'll need to
investigate but I wouldn't block M3 on this.

Any questions let me know.

Cheers,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] do_compile, the basehash value changed from...

2018-03-21 Thread Måns Zigher 
Hi,

I am seeing the following error

os-release.bb.do_compile, the basehash value changed from
b66b4812ebcc321e17478af74dc47349 to 5a21625fe0f3f42b68a1b06498b804a9. The
metadata is not deterministic and this needs to be fixed.

It appears from nowhere and I need to clean the sstate and tmp to get it to
disappear. I can build several times and then from nowhere it appears.
Where should I look to solve this? Any ideas?

BR
Mans Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH kernel 2/2] net: phy: realtek: Use the dummy stubs for MMD register access for rtl8211b

2018-03-21 Thread Kevin Hao 
From: Kevin Hao 

The Ethernet on mpc8315erdb is broken since commit b6b5e8a69118
("gianfar: Disable EEE autoneg by default"). The reason is that
even though the rtl8211b doesn't support the MMD extended registers
access, it does return some random values if we trying to access
the MMD register via indirect method. This makes it seem that the
EEE is supported by this phy device. And the subsequent writing to
the MMD registers does cause the phy malfunction. So use the dummy
stubs for the MMD register access to fix this issue.

Fixes: b6b5e8a69118 ("gianfar: Disable EEE autoneg by default")
Signed-off-by: Kevin Hao 
---
 drivers/net/phy/realtek.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index eda0a6e86918..68b4a7c61bab 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -183,6 +183,8 @@ static struct phy_driver realtek_drvs[] = {
.read_status= _read_status,
.ack_interrupt  = _ack_interrupt,
.config_intr= _config_intr,
+   .read_mmd   = _read_mmd_unsupported,
+   .write_mmd  = _write_mmd_unsupported,
}, {
.phy_id = 0x001cc914,
.name   = "RTL8211DN Gigabit Ethernet",
-- 
2.9.3

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH kernel 1/2] net: phy: Add general dummy stubs for MMD register access

2018-03-21 Thread Kevin Hao 
From: Kevin Hao 

For some phy devices, even though they don't support the MMD extended
register access, it does have some side effect if we are trying to
read/write the MMD registers via indirect method. So introduce general
dummy stubs for MMD register access which these devices can use to avoid
such side effect.

Fixes: b6b5e8a69118 ("gianfar: Disable EEE autoneg by default")
Signed-off-by: Kevin Hao 
---
 drivers/net/phy/phy_device.c | 17 +
 include/linux/phy.h  |  4 
 2 files changed, 21 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index b15b31ca2618..6893dd2a681d 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1626,6 +1626,23 @@ int genphy_config_init(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(genphy_config_init);
 
+/* This is used for the phy device which doesn't support the MMD extended
+ * register access, but it does have side effect when we are trying to access
+ * the MMD register via indirect method.
+ */
+int genphy_read_mmd_unsupported(struct phy_device *phdev, int devad, u16 
regnum)
+{
+   return -EOPNOTSUPP;
+}
+EXPORT_SYMBOL(genphy_read_mmd_unsupported);
+
+int genphy_write_mmd_unsupported(struct phy_device *phdev, int devnum,
+u16 regnum, u16 val)
+{
+   return -EOPNOTSUPP;
+}
+EXPORT_SYMBOL(genphy_write_mmd_unsupported);
+
 int genphy_suspend(struct phy_device *phydev)
 {
int value;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index dc82a07cb4fd..e6d27bc80146 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -880,6 +880,10 @@ static inline int genphy_no_soft_reset(struct phy_device 
*phydev)
 {
return 0;
 }
+int genphy_read_mmd_unsupported(struct phy_device *phdev, int devad,
+   u16 regnum);
+int genphy_write_mmd_unsupported(struct phy_device *phdev, int devnum,
+u16 regnum, u16 val);
 
 /* Clause 45 PHY */
 int genphy_c45_restart_aneg(struct phy_device *phydev);
-- 
2.9.3

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH kernel-meta] mpc8315e-rdb: Enable Realtek PHY driver

2018-03-21 Thread Kevin Hao 
A Realtek RTL8211B PHY is integrated on mpc8315erdb board. It works
pretty well with the genphy driver. But now we apply a patch for the
Realtek PHY driver in order to fix an Ethernet broken issue on this
board. So enable this chip specific driver to make sure that fix can
take effect.

Signed-off-by: Kevin Hao 
---
 bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb.cfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb.cfg 
b/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb.cfg
index 698efe2b7305..324989c1951a 100644
--- a/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb.cfg
+++ b/bsp/fsl-mpc8315e-rdb/fsl-mpc8315e-rdb.cfg
@@ -64,6 +64,7 @@ CONFIG_MTD_NAND_FSL_ELBC=y
 # Ethernet (1000 Mbit)
 #
 CONFIG_GIANFAR=y
+CONFIG_REALTEK_PHY=y
 
 #
 # Serial drivers
-- 
2.9.3

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto