[yocto] what is your way to flash for target using own image?

2016-03-20 Thread 윤영석 
Hi,
 
I have always flash own compiled binary for to check some modification.
this way, it was spending too much time.
 
So, i really want to know the effective way.
Please help and shares your wisdom.
 
Thank you.
Best Regards.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH 2/2] refpolicy: Remove 2.20140311 release.

2016-03-20 Thread Philip Tricca 
Signed-off-by: Philip Tricca 
---
 .../ftp-add-ftpd_t-to-mlsfilewrite.patch   |  39 
 .../refpolicy-2.20140311/poky-fc-clock.patch   |  22 --
 .../poky-fc-corecommands.patch |  24 ---
 .../refpolicy-2.20140311/poky-fc-dmesg.patch   |  20 --
 .../refpolicy-2.20140311/poky-fc-fix-bind.patch|  30 ---
 .../poky-fc-fix-real-path_login.patch  |  37 
 .../poky-fc-fix-real-path_resolv.conf.patch|  24 ---
 .../poky-fc-fix-real-path_shadow.patch |  34 ---
 .../poky-fc-fix-real-path_su.patch |  25 ---
 .../refpolicy-2.20140311/poky-fc-fstools.patch |  65 --
 .../refpolicy-2.20140311/poky-fc-ftpwho-dir.patch  |  27 ---
 .../refpolicy-2.20140311/poky-fc-iptables.patch|  24 ---
 .../refpolicy-2.20140311/poky-fc-mta.patch |  27 ---
 .../refpolicy-2.20140311/poky-fc-netutils.patch|  24 ---
 .../refpolicy-2.20140311/poky-fc-nscd.patch|  27 ---
 .../refpolicy-2.20140311/poky-fc-rpm.patch |  25 ---
 .../refpolicy-2.20140311/poky-fc-screen.patch  |  27 ---
 .../refpolicy-2.20140311/poky-fc-ssh.patch |  24 ---
 .../refpolicy-2.20140311/poky-fc-su.patch  |  23 ---
 .../refpolicy-2.20140311/poky-fc-subs_dist.patch   |  29 ---
 .../refpolicy-2.20140311/poky-fc-sysnetwork.patch  |  41 
 .../refpolicy-2.20140311/poky-fc-udevd.patch   |  35 
 .../poky-fc-update-alternatives_hostname.patch |  23 ---
 .../poky-fc-update-alternatives_sysklogd.patch |  59 --
 .../poky-fc-update-alternatives_sysvinit.patch |  53 -
 ...poky-policy-add-rules-for-bsdpty_device_t.patch | 121 ---
 ...ky-policy-add-rules-for-syslogd_t-symlink.patch |  30 ---
 .../poky-policy-add-rules-for-tmp-symlink.patch|  99 -
 ...ky-policy-add-rules-for-var-cache-symlink.patch |  34 ---
 ...licy-add-rules-for-var-log-symlink-apache.patch |  31 ---
 ...rules-for-var-log-symlink-audisp_remote_t.patch |  29 ---
 ...poky-policy-add-rules-for-var-log-symlink.patch | 145 -
 ...ky-policy-add-syslogd_t-to-trusted-object.patch |  31 ---
 ...-policy-allow-nfsd-to-exec-shell-commands.patch |  58 --
 ...-policy-allow-setfiles_t-to-read-symlinks.patch |  29 ---
 .../poky-policy-allow-sysadm-to-run-rpcinfo.patch  |  33 ---
 .../poky-policy-don-t-audit-tty_device_t.patch |  35 
 .../poky-policy-fix-dmesg-to-use-dev-kmsg.patch|  37 
 .../poky-policy-fix-new-SELINUXMNT-in-sys.patch| 229 -
 ...poky-policy-fix-nfsd_t-to-mount_nfsd_fs_t.patch |  65 --
 ...olicy-fix-setfiles-statvfs-get-file-count.patch |  31 ---
 ...ky-policy-fix-seutils-manage-config-files.patch |  43 
 .../refpolicy-update-for_systemd.patch |  46 -
 .../refpolicy/refpolicy-mcs_2.20140311.bb  |  11 -
 .../refpolicy/refpolicy-minimum_2.20140311.bb  |  48 -
 .../refpolicy/refpolicy-mls_2.20140311.bb  |  10 -
 .../refpolicy/refpolicy-standard_2.20140311.bb |   8 -
 .../refpolicy/refpolicy-targeted_2.20140311.bb |  20 --
 .../refpolicy/refpolicy_2.20140311.inc |  60 --
 49 files changed, 2071 deletions(-)
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/ftp-add-ftpd_t-to-mlsfilewrite.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-clock.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-corecommands.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-dmesg.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-fix-bind.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-fix-real-path_login.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-fix-real-path_resolv.conf.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-fix-real-path_shadow.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-fix-real-path_su.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-fstools.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-ftpwho-dir.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-iptables.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-mta.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-netutils.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-nscd.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-rpm.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-screen.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-ssh.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-2.20140311/poky-fc-su.patch
 delete mode 100644

[yocto] [meta-selinux][PATCH 0/2] policy upgrade and cleanup

2016-03-20 Thread Philip Tricca 
By default we build *_git refpolicy packages. The release packages
have been lagging behind. The first patch replaces the 2.2014120
release with the latest (2.20151208). The second removes the old
2.20140311 release.

Philip Tricca (2):
  refpolicy: Replace 2.2014120 with release 2.20151208.
  refpolicy: Remove 2.20140311 release.

 .../ftp-add-ftpd_t-to-mlsfilewrite.patch   |  39 
 .../refpolicy-2.20140311/poky-fc-clock.patch   |  22 --
 .../poky-fc-corecommands.patch |  24 ---
 .../refpolicy-2.20140311/poky-fc-dmesg.patch   |  20 --
 .../refpolicy-2.20140311/poky-fc-fix-bind.patch|  30 ---
 .../poky-fc-fix-real-path_login.patch  |  37 
 .../poky-fc-fix-real-path_resolv.conf.patch|  24 ---
 .../poky-fc-fix-real-path_shadow.patch |  34 ---
 .../poky-fc-fix-real-path_su.patch |  25 ---
 .../refpolicy-2.20140311/poky-fc-fstools.patch |  65 --
 .../refpolicy-2.20140311/poky-fc-ftpwho-dir.patch  |  27 ---
 .../refpolicy-2.20140311/poky-fc-iptables.patch|  24 ---
 .../refpolicy-2.20140311/poky-fc-mta.patch |  27 ---
 .../refpolicy-2.20140311/poky-fc-netutils.patch|  24 ---
 .../refpolicy-2.20140311/poky-fc-nscd.patch|  27 ---
 .../refpolicy-2.20140311/poky-fc-rpm.patch |  25 ---
 .../refpolicy-2.20140311/poky-fc-screen.patch  |  27 ---
 .../refpolicy-2.20140311/poky-fc-ssh.patch |  24 ---
 .../refpolicy-2.20140311/poky-fc-su.patch  |  23 ---
 .../refpolicy-2.20140311/poky-fc-subs_dist.patch   |  29 ---
 .../refpolicy-2.20140311/poky-fc-sysnetwork.patch  |  41 
 .../refpolicy-2.20140311/poky-fc-udevd.patch   |  35 
 .../poky-fc-update-alternatives_hostname.patch |  23 ---
 .../poky-fc-update-alternatives_sysklogd.patch |  59 --
 .../poky-fc-update-alternatives_sysvinit.patch |  53 -
 ...poky-policy-add-rules-for-bsdpty_device_t.patch | 121 ---
 ...ky-policy-add-rules-for-syslogd_t-symlink.patch |  30 ---
 .../poky-policy-add-rules-for-tmp-symlink.patch|  99 -
 ...ky-policy-add-rules-for-var-cache-symlink.patch |  34 ---
 ...licy-add-rules-for-var-log-symlink-apache.patch |  31 ---
 ...rules-for-var-log-symlink-audisp_remote_t.patch |  29 ---
 ...poky-policy-add-rules-for-var-log-symlink.patch | 145 -
 ...ky-policy-add-syslogd_t-to-trusted-object.patch |  31 ---
 ...-policy-allow-nfsd-to-exec-shell-commands.patch |  58 --
 ...-policy-allow-setfiles_t-to-read-symlinks.patch |  29 ---
 .../poky-policy-allow-sysadm-to-run-rpcinfo.patch  |  33 ---
 .../poky-policy-don-t-audit-tty_device_t.patch |  35 
 .../poky-policy-fix-dmesg-to-use-dev-kmsg.patch|  37 
 .../poky-policy-fix-new-SELINUXMNT-in-sys.patch| 229 -
 ...poky-policy-fix-nfsd_t-to-mount_nfsd_fs_t.patch |  65 --
 ...olicy-fix-setfiles-statvfs-get-file-count.patch |  31 ---
 ...ky-policy-fix-seutils-manage-config-files.patch |  43 
 .../refpolicy-update-for_systemd.patch |  46 -
 .../ftp-add-ftpd_t-to-mlsfilewrite.patch   |  39 
 .../refpolicy-2.20141203/poky-fc-clock.patch   |  22 --
 .../poky-fc-corecommands.patch |  24 ---
 .../refpolicy-2.20141203/poky-fc-dmesg.patch   |  20 --
 .../refpolicy-2.20141203/poky-fc-fix-bind.patch|  30 ---
 .../poky-fc-fix-real-path_login.patch  |  37 
 .../poky-fc-fix-real-path_resolv.conf.patch|  24 ---
 .../poky-fc-fix-real-path_shadow.patch |  34 ---
 .../poky-fc-fix-real-path_su.patch |  25 ---
 .../refpolicy-2.20141203/poky-fc-fstools.patch |  70 ---
 .../refpolicy-2.20141203/poky-fc-ftpwho-dir.patch  |  27 ---
 .../refpolicy-2.20141203/poky-fc-iptables.patch|  24 ---
 .../refpolicy-2.20141203/poky-fc-mta.patch |  27 ---
 .../refpolicy-2.20141203/poky-fc-netutils.patch|  24 ---
 .../refpolicy-2.20141203/poky-fc-nscd.patch|  27 ---
 .../refpolicy-2.20141203/poky-fc-rpm.patch |  25 ---
 .../refpolicy-2.20141203/poky-fc-screen.patch  |  27 ---
 .../refpolicy-2.20141203/poky-fc-ssh.patch |  24 ---
 .../refpolicy-2.20141203/poky-fc-su.patch  |  23 ---
 .../refpolicy-2.20141203/poky-fc-subs_dist.patch   |  29 ---
 .../refpolicy-2.20141203/poky-fc-sysnetwork.patch  |  46 -
 .../refpolicy-2.20141203/poky-fc-udevd.patch   |  35 
 .../poky-fc-update-alternatives_hostname.patch |  23 ---
 .../poky-fc-update-alternatives_sysklogd.patch |  59 --
 .../poky-fc-update-alternatives_sysvinit.patch |  53 -
 ...poky-policy-add-rules-for-bsdpty_device_t.patch | 121 ---
 ...ky-policy-add-rules-for-syslogd_t-symlink.patch |  30 ---
 .../poky-policy-add-rules-for-tmp-symlink.patch|  99 -
 ...ky-policy-add-rules-for-var-cache-symlink.patch |  34 ---
 ...licy-add-rules-for-var-log-symlink-apache.patch |  31 ---

[linux-yocto] [PATCH 09/11] ACPI / property: Extend fwnode_property_* to data-only subnodes

2016-03-20 Thread weifeng . voon 
From: "Rafael J. Wysocki" 

Modify is_acpi_node() to return "true" for ACPI data-only subnodes as
well as for ACPI device objects and change the name of to_acpi_node()
to to_acpi_device_node() so it is clear that it covers ACPI device
objects only.  Accordingly, introduce to_acpi_data_node() to cover
data-only subnodes in an analogous way.

With that, make the fwnode_property_* family of functions work with
ACPI data-only subnodes introduced previously.

Signed-off-by: Rafael J. Wysocki 
Tested-by: Mika Westerberg 
(cherry picked from commit 3a7a2ab839ad18c2d542b40f4a647c98d068e55a)
Signed-off-by: Voon, Weifeng 
---
 drivers/acpi/property.c | 138 
 drivers/base/property.c |  16 +++---
 drivers/gpio/gpiolib.c  |   6 +--
 include/acpi/acpi_bus.h |  21 +++-
 include/linux/acpi.h|  53 +--
 5 files changed, 173 insertions(+), 61 deletions(-)

diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 17c436d..5859fd1 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -19,6 +19,11 @@
 
 #include "internal.h"
 
+static int acpi_data_get_property_array(struct acpi_device_data *data,
+   const char *name,
+   acpi_object_type type,
+   const union acpi_object **obj);
+
 /* ACPI _DSD device properties UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 */
 static const u8 prp_uuid[16] = {
0x14, 0xd8, 0xff, 0xda, 0xba, 0x6e, 0x8c, 0x4d,
@@ -190,8 +195,8 @@ static void acpi_init_of_compatible(struct acpi_device 
*adev)
const union acpi_object *of_compatible;
int ret;
 
-   ret = acpi_dev_get_property_array(adev, "compatible", ACPI_TYPE_STRING,
- _compatible);
+   ret = acpi_data_get_property_array(>data, "compatible",
+  ACPI_TYPE_STRING, _compatible);
if (ret) {
ret = acpi_dev_get_property(adev, "compatible",
ACPI_TYPE_STRING, _compatible);
@@ -318,8 +323,8 @@ void acpi_free_properties(struct acpi_device *adev)
 }
 
 /**
- * acpi_dev_get_property - return an ACPI property with given name
- * @adev: ACPI device to get property
+ * acpi_data_get_property - return an ACPI property with given name
+ * @data: ACPI device deta object to get the property from
  * @name: Name of the property
  * @type: Expected property type
  * @obj: Location to store the property value (if not %NULL)
@@ -328,26 +333,27 @@ void acpi_free_properties(struct acpi_device *adev)
  * object at the location pointed to by @obj if found.
  *
  * Callers must not attempt to free the returned objects.  These objects will 
be
- * freed by the ACPI core automatically during the removal of @adev.
+ * freed by the ACPI core automatically during the removal of @data.
  *
  * Return: %0 if property with @name has been found (success),
  * %-EINVAL if the arguments are invalid,
  * %-ENODATA if the property doesn't exist,
  * %-EPROTO if the property value type doesn't match @type.
  */
-int acpi_dev_get_property(struct acpi_device *adev, const char *name,
- acpi_object_type type, const union acpi_object **obj)
+static int acpi_data_get_property(struct acpi_device_data *data,
+ const char *name, acpi_object_type type,
+ const union acpi_object **obj)
 {
const union acpi_object *properties;
int i;
 
-   if (!adev || !name)
+   if (!data || !name)
return -EINVAL;
 
-   if (!adev->data.pointer || !adev->data.properties)
+   if (!data->pointer || !data->properties)
return -ENODATA;
 
-   properties = adev->data.properties;
+   properties = data->properties;
for (i = 0; i < properties->package.count; i++) {
const union acpi_object *propname, *propvalue;
const union acpi_object *property;
@@ -368,11 +374,50 @@ int acpi_dev_get_property(struct acpi_device *adev, const 
char *name,
}
return -ENODATA;
 }
+
+/**
+ * acpi_dev_get_property - return an ACPI property with given name.
+ * @adev: ACPI device to get the property from.
+ * @name: Name of the property.
+ * @type: Expected property type.
+ * @obj: Location to store the property value (if not %NULL).
+ */
+int acpi_dev_get_property(struct acpi_device *adev, const char *name,
+ acpi_object_type type, const union acpi_object **obj)
+{
+   return adev ? acpi_data_get_property(>data, name, type, obj) : 
-EINVAL;
+}
 EXPORT_SYMBOL_GPL(acpi_dev_get_property);
 
+static struct acpi_device_data *acpi_device_data_of_node(struct fwnode_handle 
*fwnode)
+{
+   if

[linux-yocto] [PATCH 10/11] device property: fallback to pset when gettng one string

2016-03-20 Thread weifeng . voon 
From: Andy Shevchenko 

The one string as an equivalent to an array of one element. Allow user to read
one string as a plain string.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
(cherry picked from commit 4f73b0654d8a954540d49bb0a300f31663423db9)
Signed-off-by: Voon, Weifeng 
---
 drivers/base/property.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index dce2331..e5b4385 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -470,7 +470,8 @@ int fwnode_property_read_string(struct fwnode_handle 
*fwnode,
return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
   val, 1);
 
-   return -ENXIO;
+   return pset_prop_read_array(to_pset(fwnode), propname,
+   DEV_PROP_STRING, val, 1);
 }
 EXPORT_SYMBOL_GPL(fwnode_property_read_string);
 
-- 
1.9.1

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

[linux-yocto] [PATCH 11/11] device property: always check for fwnode type

2016-03-20 Thread weifeng . voon 
From: Andy Shevchenko 

Currently the property accessors unconditionally fall back to built-in property
set as a last resort. Make this strict and return an error in case the type of
fwnode is unknown.

This is actually a follow up to the commit 4fa7508e9f1c (device property:
Return -ENXIO if there is no suitable FW interface).

Signed-off-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki 
(cherry picked from commit e3f9e299bf94298ddd8beb63c0786a4d7766dc86)
Signed-off-by: Voon, Weifeng 
---
 drivers/base/property.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index e5b4385..66672dd 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -132,8 +132,9 @@ bool fwnode_property_present(struct fwnode_handle *fwnode, 
const char *propname)
return of_property_read_bool(to_of_node(fwnode), propname);
else if (is_acpi_node(fwnode))
return !acpi_node_prop_get(fwnode, propname, NULL);
-
-   return !!pset_prop_get(to_pset(fwnode), propname);
+   else if (is_pset(fwnode))
+   return !!pset_prop_get(to_pset(fwnode), propname);
+   return false;
 }
 EXPORT_SYMBOL_GPL(fwnode_property_present);
 
@@ -469,9 +470,10 @@ int fwnode_property_read_string(struct fwnode_handle 
*fwnode,
else if (is_acpi_node(fwnode))
return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
   val, 1);
-
-   return pset_prop_read_array(to_pset(fwnode), propname,
-   DEV_PROP_STRING, val, 1);
+   else if (is_pset(fwnode))
+   return pset_prop_read_array(to_pset(fwnode), propname,
+   DEV_PROP_STRING, val, 1);
+   return -ENXIO;
 }
 EXPORT_SYMBOL_GPL(fwnode_property_read_string);
 
-- 
1.9.1

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

[linux-yocto] [PATCH 03/11] ACPI / scan: Parse _CCA and setup device coherency

2016-03-20 Thread weifeng . voon 
From: "Suthikulpanit, Suravee" 

This patch implements support for ACPI _CCA object, which is introduced in
ACPIv5.1, can be used for specifying device DMA coherency attribute.

The parsing logic traverses device namespace to parse coherency
information, and stores it in acpi_device_flags. Then uses it to call
arch_setup_dma_ops() when creating each device enumerated in DSDT
during ACPI scan.

This patch also introduces acpi_dma_is_coherent(), which provides
an interface for device drivers to check the coherency information
similarly to the of_dma_is_coherent().

Signed-off-by: Mark Salter 
Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Rafael J. Wysocki 
(cherry picked from commit d0562674838c08ff142c0e9a8e12634e133c4361)
Signed-off-by: Voon, Weifeng 
---
 drivers/acpi/Kconfig |  3 +++
 drivers/acpi/acpi_platform.c |  2 +-
 drivers/acpi/glue.c  |  5 +
 drivers/acpi/scan.c  | 35 +++
 include/acpi/acpi_bus.h  | 37 -
 include/linux/acpi.h |  5 +
 6 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index ab2cbb5..212735f 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -54,6 +54,9 @@ config ACPI_GENERIC_GSI
 config ACPI_SYSTEM_POWER_STATES_SUPPORT
bool
 
+config ACPI_CCA_REQUIRED
+   bool
+
 config ACPI_SLEEP
bool
depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 4bf7559..06a67d5 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -103,7 +103,7 @@ struct platform_device *acpi_create_platform_device(struct 
acpi_device *adev)
pdevinfo.res = resources;
pdevinfo.num_res = count;
pdevinfo.fwnode = acpi_fwnode_handle(adev);
-   pdevinfo.dma_mask = DMA_BIT_MASK(32);
+   pdevinfo.dma_mask = acpi_check_dma(adev, NULL) ? DMA_BIT_MASK(32) : 0;
pdev = platform_device_register_full();
if (IS_ERR(pdev))
dev_err(>dev, "platform device creation failed: %ld\n",
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 39c485b..b9657af 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device 
*acpi_dev)
struct list_head *physnode_list;
unsigned int node_id;
int retval = -EINVAL;
+   bool coherent;
 
if (has_acpi_companion(dev)) {
if (acpi_dev) {
@@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device 
*acpi_dev)
if (!has_acpi_companion(dev))
ACPI_COMPANION_SET(dev, acpi_dev);
 
+   if (acpi_check_dma(acpi_dev, ))
+   arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
+
acpi_physnode_link_name(physical_node_name, node_id);
retval = sysfs_create_link(_dev->dev.kobj, >kobj,
   physical_node_name);
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index b19283b..1cf1650 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -2111,6 +2112,39 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp)
kfree(pnp->unique_id);
 }
 
+static void acpi_init_coherency(struct acpi_device *adev)
+{
+   unsigned long long cca = 0;
+   acpi_status status;
+   struct acpi_device *parent = adev->parent;
+
+   if (parent && parent->flags.cca_seen) {
+   /*
+* From ACPI spec, OSPM will ignore _CCA if an ancestor
+* already saw one.
+*/
+   adev->flags.cca_seen = 1;
+   cca = parent->flags.coherent_dma;
+   } else {
+   status = acpi_evaluate_integer(adev->handle, "_CCA",
+  NULL, );
+   if (ACPI_SUCCESS(status))
+   adev->flags.cca_seen = 1;
+   else if (!IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED))
+   /*
+* If architecture does not specify that _CCA is
+* required for DMA-able devices (e.g. x86),
+* we default to _CCA=1.
+*/
+   cca = 1;
+   else
+   acpi_handle_debug(adev->handle,
+ "ACPI device is missing _CCA.\n");
+   }
+
+   adev->flags.coherent_dma = cca;
+}
+
 void acpi_init_device_object(struct acpi_device *device, acpi_handle handle,
 int type, unsigned long long sta)
 {
@@ -2129,6 +2163,7 @@

[linux-yocto] [PATCH 04/11] ACPI / OF: Rename of_node() and acpi_node() to to_of_node() and to_acpi_node()

2016-03-20 Thread weifeng . voon 
From: Alexander Sverdlin 

Commit 8a0662d9 introduced of_node and acpi_node symbols in global namespace
but there were already ~63 of_node local variables or function parameters
(no single acpi_node though, but anyway).

After debugging undefined but used of_node local varible (which turned out
to reference static function of_node() instead) it became clear that the names
for the functions are too short and too generic for global scope.

Signed-off-by: Alexander Sverdlin 
Signed-off-by: Rafael J. Wysocki 
(cherry picked from commit c181fb3e723351e2f7a1f76b6c0627a4b8ad1723)
Signed-off-by: Voon, Weifeng 
---
 drivers/base/property.c  | 26 +-
 drivers/gpio/gpiolib.c   |  4 ++--
 drivers/leds/leds-gpio.c |  2 +-
 include/acpi/acpi_bus.h  |  2 +-
 include/linux/acpi.h |  4 ++--
 include/linux/of.h   |  4 ++--
 6 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 0a60ef1..84a080b 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -129,9 +129,9 @@ EXPORT_SYMBOL_GPL(device_property_present);
 bool fwnode_property_present(struct fwnode_handle *fwnode, const char 
*propname)
 {
if (is_of_node(fwnode))
-   return of_property_read_bool(of_node(fwnode), propname);
+   return of_property_read_bool(to_of_node(fwnode), propname);
else if (is_acpi_node(fwnode))
-   return !acpi_dev_prop_get(acpi_node(fwnode), propname, NULL);
+   return !acpi_dev_prop_get(to_acpi_node(fwnode), propname, NULL);
 
return !!pset_prop_get(to_pset(fwnode), propname);
 }
@@ -286,10 +286,10 @@ EXPORT_SYMBOL_GPL(device_property_read_string);
 ({ \
int _ret_; \
if (is_of_node(_fwnode_)) \
-   _ret_ = OF_DEV_PROP_READ_ARRAY(of_node(_fwnode_), _propname_, \
+   _ret_ = OF_DEV_PROP_READ_ARRAY(to_of_node(_fwnode_), 
_propname_, \
   _type_, _val_, _nval_); \
else if (is_acpi_node(_fwnode_)) \
-   _ret_ = acpi_dev_prop_read(acpi_node(_fwnode_), _propname_, \
+   _ret_ = acpi_dev_prop_read(to_acpi_node(_fwnode_), _propname_, \
   _proptype_, _val_, _nval_); \
else \
_ret_ = pset_prop_read_array(to_pset(_fwnode_), _propname_, \
@@ -425,11 +425,11 @@ int fwnode_property_read_string_array(struct 
fwnode_handle *fwnode,
 {
if (is_of_node(fwnode))
return val ?
-   of_property_read_string_array(of_node(fwnode), propname,
- val, nval) :
-   of_property_count_strings(of_node(fwnode), propname);
+   of_property_read_string_array(to_of_node(fwnode),
+ propname, val, nval) :
+   of_property_count_strings(to_of_node(fwnode), propname);
else if (is_acpi_node(fwnode))
-   return acpi_dev_prop_read(acpi_node(fwnode), propname,
+   return acpi_dev_prop_read(to_acpi_node(fwnode), propname,
  DEV_PROP_STRING, val, nval);
 
return pset_prop_read_array(to_pset(fwnode), propname,
@@ -456,9 +456,9 @@ int fwnode_property_read_string(struct fwnode_handle 
*fwnode,
const char *propname, const char **val)
 {
if (is_of_node(fwnode))
-   return of_property_read_string(of_node(fwnode), propname, val);
+   return of_property_read_string(to_of_node(fwnode), propname, 
val);
else if (is_acpi_node(fwnode))
-   return acpi_dev_prop_read(acpi_node(fwnode), propname,
+   return acpi_dev_prop_read(to_acpi_node(fwnode), propname,
  DEV_PROP_STRING, val, 1);
 
return -ENXIO;
@@ -476,13 +476,13 @@ struct fwnode_handle *device_get_next_child_node(struct 
device *dev,
if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
struct device_node *node;
 
-   node = of_get_next_available_child(dev->of_node, 
of_node(child));
+   node = of_get_next_available_child(dev->of_node, 
to_of_node(child));
if (node)
return >fwnode;
} else if (IS_ENABLED(CONFIG_ACPI)) {
struct acpi_device *node;
 
-   node = acpi_get_next_child(dev, acpi_node(child));
+   node = acpi_get_next_child(dev, to_acpi_node(child));
if (node)
return acpi_fwnode_handle(node);
}
@@ -501,7 +501,7 @@ EXPORT_SYMBOL_GPL(device_get_next_child_node);
 void fwnode_handle_put(struct fwnode_handle *fwnode)
 {
if (is_of_node(fwnode))
-

[linux-yocto] [PATCH 07/11] ACPI / property: Add routine for extraction of _DSD properties

2016-03-20 Thread weifeng . voon 
From: "Rafael J. Wysocki" 

Move the extraction of _DSD properties from acpi_init_properties()
to a separate routine called acpi_extract_properties() to make the
subsequent changes more straightforward.

Signed-off-by: Rafael J. Wysocki 
Tested-by: Mika Westerberg 
(cherry picked from commit bd8191cc8a74018e255eb3efff5e02dc305a5ed1)
Signed-off-by: Voon, Weifeng 
---
 drivers/acpi/property.c | 69 ++---
 1 file changed, 37 insertions(+), 32 deletions(-)

diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 6d99450..8163b4b 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -100,34 +100,13 @@ static void acpi_init_of_compatible(struct acpi_device 
*adev)
adev->flags.of_compatible_ok = 1;
 }
 
-void acpi_init_properties(struct acpi_device *adev)
+static bool acpi_extract_properties(const union acpi_object *desc,
+   struct acpi_device_data *data)
 {
-   struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
-   bool acpi_of = false;
-   struct acpi_hardware_id *hwid;
-   const union acpi_object *desc;
-   acpi_status status;
int i;
 
-   /*
-* Check if ACPI_DT_NAMESPACE_HID is present and inthat case we fill in
-* Device Tree compatible properties for this device.
-*/
-   list_for_each_entry(hwid, >pnp.ids, list) {
-   if (!strcmp(hwid->id, ACPI_DT_NAMESPACE_HID)) {
-   acpi_of = true;
-   break;
-   }
-   }
-
-   status = acpi_evaluate_object_typed(adev->handle, "_DSD", NULL, ,
-   ACPI_TYPE_PACKAGE);
-   if (ACPI_FAILURE(status))
-   goto out;
-
-   desc = buf.pointer;
if (desc->package.count % 2)
-   goto fail;
+   return false;
 
/* Look for the device properties UUID. */
for (i = 0; i < desc->package.count; i += 2) {
@@ -154,18 +133,44 @@ void acpi_init_properties(struct acpi_device *adev)
if (!acpi_properties_format_valid(properties))
break;
 
-   adev->data.pointer = buf.pointer;
-   adev->data.properties = properties;
+   data->properties = properties;
+   return true;
+   }
 
-   if (acpi_of)
-   acpi_init_of_compatible(adev);
+   return false;
+}
 
-   goto out;
+void acpi_init_properties(struct acpi_device *adev)
+{
+   struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
+   struct acpi_hardware_id *hwid;
+   acpi_status status;
+   bool acpi_of = false;
+
+   /*
+* Check if ACPI_DT_NAMESPACE_HID is present and inthat case we fill in
+* Device Tree compatible properties for this device.
+*/
+   list_for_each_entry(hwid, >pnp.ids, list) {
+   if (!strcmp(hwid->id, ACPI_DT_NAMESPACE_HID)) {
+   acpi_of = true;
+   break;
+   }
}
 
- fail:
-   dev_dbg(>dev, "Returned _DSD data is not valid, skipping\n");
-   ACPI_FREE(buf.pointer);
+   status = acpi_evaluate_object_typed(adev->handle, "_DSD", NULL, ,
+   ACPI_TYPE_PACKAGE);
+   if (ACPI_FAILURE(status))
+   goto out;
+
+   if (acpi_extract_properties(buf.pointer, >data)) {
+   adev->data.pointer = buf.pointer;
+   if (acpi_of)
+   acpi_init_of_compatible(adev);
+   } else {
+   acpi_handle_debug(adev->handle, "Invalid _DSD data, 
skipping\n");
+   ACPI_FREE(buf.pointer);
+   }
 
  out:
if (acpi_of && !adev->flags.of_compatible_ok)
-- 
1.9.1

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

[linux-yocto] [PATCH 08/11] ACPI / property: Add support for data-only subnodes

2016-03-20 Thread weifeng . voon 
From: "Rafael J. Wysocki" 

In some cases, the information expressed via device properties is
hierarchical by nature.  For example, the properties of a composite
device consisting of multiple semi-dependent components may need
to be represented in the form of a tree of property data sets
corresponding to specific components of the device.

Unfortunately, using ACPI device objects for this purpose turns out
to be problematic, mostly due to the assumption made by some operating
systems (that platform firmware generally needs to work with) that
each device object in the ACPI namespace represents a device requiring
a separate driver.  That assumption leads to complications which
reportedly are impractically difficult to overcome and a different
approach is needed for the sake of interoperability.

The approach implemented here is based on extending _DSD via pointers
(links) to additional ACPI objects returning data packages formatted
in accordance with the _DSD formatting rules defined by Section 6.2.5
of ACPI 6.  Those additional objects are referred to as data-only
subnodes of the device object containing the _DSD pointing to them.

The links to them need to be located in a separate section of the
_DSD data package following UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b
referred to as the Hierarchical Data Extension UUID as defined in [1].
Each of them is represented by a package of two strings.  The first
string in that package (the key) is regarded as the name of the
data-only subnode pointed to by the link.  The second string in it
(the target) is expected to hold the ACPI namespace path (possibly
utilizing the usual ACPI namespace search rules) of an ACPI object
evaluating to a data package extending the _DSD.

The device properties initialization code follows those links,
creates a struct acpi_data_node object for each of them to store
the data returned by the ACPI object pointed to by it and processes
those data recursively (which may lead to the creation of more
struct acpi_data_node objects if the returned data package contains
the Hierarchical Data Extension UUID section with more links in it).

All of the struct acpi_data_node objects are present until the the
ACPI device object containing the _DSD with links to them is deleted
and they are deleted along with that object.

[1]: 
http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf

Signed-off-by: Rafael J. Wysocki 
Tested-by: Mika Westerberg 
(cherry picked from commit 445b0eb058f5f31c844a731cb82e7441d0d9e578)
Signed-off-by: Voon, Weifeng 
---
 drivers/acpi/property.c | 133 +++-
 include/acpi/acpi_bus.h |   9 
 include/linux/fwnode.h  |   1 +
 3 files changed, 142 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 8163b4b..17c436d 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -24,6 +24,115 @@ static const u8 prp_uuid[16] = {
0x14, 0xd8, 0xff, 0xda, 0xba, 0x6e, 0x8c, 0x4d,
0x8a, 0x91, 0xbc, 0x9b, 0xbf, 0x4a, 0xa3, 0x01
 };
+/* ACPI _DSD data subnodes UUID: dbb8e3e6-5886-4ba6-8795-1319f52a966b */
+static const u8 ads_uuid[16] = {
+   0xe6, 0xe3, 0xb8, 0xdb, 0x86, 0x58, 0xa6, 0x4b,
+   0x87, 0x95, 0x13, 0x19, 0xf5, 0x2a, 0x96, 0x6b
+};
+
+static bool acpi_enumerate_nondev_subnodes(acpi_handle scope,
+  const union acpi_object *desc,
+  struct acpi_device_data *data);
+static bool acpi_extract_properties(const union acpi_object *desc,
+   struct acpi_device_data *data);
+
+static bool acpi_nondev_subnode_ok(acpi_handle scope,
+  const union acpi_object *link,
+  struct list_head *list)
+{
+   struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
+   struct acpi_data_node *dn;
+   acpi_handle handle;
+   acpi_status status;
+
+   dn = kzalloc(sizeof(*dn), GFP_KERNEL);
+   if (!dn)
+   return false;
+
+   dn->name = link->package.elements[0].string.pointer;
+   dn->fwnode.type = FWNODE_ACPI_DATA;
+   INIT_LIST_HEAD(>data.subnodes);
+
+   status = acpi_get_handle(scope, 
link->package.elements[1].string.pointer,
+);
+   if (ACPI_FAILURE(status))
+   goto fail;
+
+   status = acpi_evaluate_object_typed(handle, NULL, NULL, ,
+   ACPI_TYPE_PACKAGE);
+   if (ACPI_FAILURE(status))
+   goto fail;
+
+   if (acpi_extract_properties(buf.pointer, >data))
+   dn->data.pointer = buf.pointer;
+
+   if (acpi_enumerate_nondev_subnodes(scope, buf.pointer, >data))
+   dn->data.pointer = buf.pointer;
+
+   if

[linux-yocto] [PATCH 06/11] device property: Return -ENXIO if there is no suitable FW interface

2016-03-20 Thread weifeng . voon 
From: Guenter Roeck 

Return -ENXIO if device property array access functions don't find
a suitable firmware interface.

This lets drivers decide if they should use available platform data
instead.

Cc: Rafael J. Wysocki 
Signed-off-by: Guenter Roeck 
Tested-by: Jeremy Linton 
Signed-off-by: David S. Miller 
(cherry picked from commit 4fa7508e9f1c64ae39516e40ee5495aaa4616ad7)
Signed-off-by: Voon, Weifeng 
---
 drivers/base/property.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 84a080b..33013b1 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -153,6 +153,7 @@ EXPORT_SYMBOL_GPL(fwnode_property_present);
  *%-ENODATA if the property does not have a value,
  *%-EPROTO if the property is not an array of numbers,
  *%-EOVERFLOW if the size of the property is not as expected.
+ *%-ENXIO if no suitable firmware interface is present.
  */
 int device_property_read_u8_array(struct device *dev, const char *propname,
  u8 *val, size_t nval)
@@ -177,6 +178,7 @@ EXPORT_SYMBOL_GPL(device_property_read_u8_array);
  *%-ENODATA if the property does not have a value,
  *%-EPROTO if the property is not an array of numbers,
  *%-EOVERFLOW if the size of the property is not as expected.
+ *%-ENXIO if no suitable firmware interface is present.
  */
 int device_property_read_u16_array(struct device *dev, const char *propname,
   u16 *val, size_t nval)
@@ -201,6 +203,7 @@ EXPORT_SYMBOL_GPL(device_property_read_u16_array);
  *%-ENODATA if the property does not have a value,
  *%-EPROTO if the property is not an array of numbers,
  *%-EOVERFLOW if the size of the property is not as expected.
+ *%-ENXIO if no suitable firmware interface is present.
  */
 int device_property_read_u32_array(struct device *dev, const char *propname,
   u32 *val, size_t nval)
@@ -225,6 +228,7 @@ EXPORT_SYMBOL_GPL(device_property_read_u32_array);
  *%-ENODATA if the property does not have a value,
  *%-EPROTO if the property is not an array of numbers,
  *%-EOVERFLOW if the size of the property is not as expected.
+ *%-ENXIO if no suitable firmware interface is present.
  */
 int device_property_read_u64_array(struct device *dev, const char *propname,
   u64 *val, size_t nval)
@@ -249,6 +253,7 @@ EXPORT_SYMBOL_GPL(device_property_read_u64_array);
  *%-ENODATA if the property does not have a value,
  *%-EPROTO or %-EILSEQ if the property is not an array of strings,
  *%-EOVERFLOW if the size of the property is not as expected.
+ *%-ENXIO if no suitable firmware interface is present.
  */
 int device_property_read_string_array(struct device *dev, const char *propname,
  const char **val, size_t nval)
@@ -270,6 +275,7 @@ EXPORT_SYMBOL_GPL(device_property_read_string_array);
  *%-EINVAL if given arguments are not valid,
  *%-ENODATA if the property does not have a value,
  *%-EPROTO or %-EILSEQ if the property type is not a string.
+ *%-ENXIO if no suitable firmware interface is present.
  */
 int device_property_read_string(struct device *dev, const char *propname,
const char **val)
@@ -291,9 +297,11 @@ EXPORT_SYMBOL_GPL(device_property_read_string);
else if (is_acpi_node(_fwnode_)) \
_ret_ = acpi_dev_prop_read(to_acpi_node(_fwnode_), _propname_, \
   _proptype_, _val_, _nval_); \
-   else \
+   else if (is_pset(_fwnode_)) \
_ret_ = pset_prop_read_array(to_pset(_fwnode_), _propname_, \
 _proptype_, _val_, _nval_); \
+   else \
+   _ret_ = -ENXIO; \
_ret_; \
 })
 
@@ -431,9 +439,10 @@ int fwnode_property_read_string_array(struct fwnode_handle 
*fwnode,
else if (is_acpi_node(fwnode))
return acpi_dev_prop_read(to_acpi_node(fwnode), propname,
  DEV_PROP_STRING, val, nval);
-
-   return pset_prop_read_array(to_pset(fwnode), propname,
-   DEV_PROP_STRING, val, nval);
+   else if (is_pset(fwnode))
+   return pset_prop_read_array(to_pset(fwnode), propname,
+   DEV_PROP_STRING, val, nval);
+   return -ENXIO;
 }
 EXPORT_SYMBOL_GPL(fwnode_property_read_string_array);
 
-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org

[linux-yocto] [PATCH 02/11] ACPI / property: Define a symbol for PRP0001

2016-03-20 Thread weifeng . voon 
From: "Rafael J. Wysocki" 

Use a #defined symbol ACPI_DT_NAMESPACE_HID instead of the PRP0001
string.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Mika Westerberg 
Reviewed-by: Hanjun Guo 
(cherry picked from commit ee89209402e0b9a733169901063afdf0ae7909db)
Signed-off-by: Voon, Weifeng 
---
 drivers/acpi/internal.h |  2 ++
 drivers/acpi/property.c |  8 
 drivers/acpi/scan.c | 28 +++-
 3 files changed, 21 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index ba4a61e..d93628c 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -191,6 +191,8 @@ bool acpi_osi_is_win8(void);
 /*--
Device properties
   -- */
+#define ACPI_DT_NAMESPACE_HID  "PRP0001"
+
 void acpi_init_properties(struct acpi_device *adev);
 void acpi_free_properties(struct acpi_device *adev);
 
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 76075ee..7836e2e 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -110,11 +110,11 @@ void acpi_init_properties(struct acpi_device *adev)
int i;
 
/*
-* Check if the special PRP0001 ACPI ID is present and in that case we
-* fill in Device Tree compatible properties for this device.
+* Check if ACPI_DT_NAMESPACE_HID is present and inthat case we fill in
+* Device Tree compatible properties for this device.
 */
list_for_each_entry(hwid, >pnp.ids, list) {
-   if (!strcmp(hwid->id, "PRP0001")) {
+   if (!strcmp(hwid->id, ACPI_DT_NAMESPACE_HID)) {
acpi_of = true;
break;
}
@@ -170,7 +170,7 @@ void acpi_init_properties(struct acpi_device *adev)
  out:
if (acpi_of && !adev->flags.of_compatible_ok)
acpi_handle_info(adev->handle,
-"PRP0001 requires 'compatible' property\n");
+ACPI_DT_NAMESPACE_HID " requires 'compatible' 
property\n");
 }
 
 void acpi_free_properties(struct acpi_device *adev)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 03141aa..b19283b 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -135,12 +135,13 @@ static int create_pnp_modalias(struct acpi_device 
*acpi_dev, char *modalias,
struct acpi_hardware_id *id;
 
/*
-* Since we skip PRP0001 from the modalias below, 0 should be returned
-* if PRP0001 is the only ACPI/PNP ID in the device's list.
+* Since we skip ACPI_DT_NAMESPACE_HID from the modalias below, 0 should
+* be returned if ACPI_DT_NAMESPACE_HID is the only ACPI/PNP ID in the
+* device's list.
 */
count = 0;
list_for_each_entry(id, _dev->pnp.ids, list)
-   if (strcmp(id->id, "PRP0001"))
+   if (strcmp(id->id, ACPI_DT_NAMESPACE_HID))
count++;
 
if (!count)
@@ -153,7 +154,7 @@ static int create_pnp_modalias(struct acpi_device 
*acpi_dev, char *modalias,
size -= len;
 
list_for_each_entry(id, _dev->pnp.ids, list) {
-   if (!strcmp(id->id, "PRP0001"))
+   if (!strcmp(id->id, ACPI_DT_NAMESPACE_HID))
continue;
 
count = snprintf([len], size, "%s:", id->id);
@@ -177,7 +178,8 @@ static int create_pnp_modalias(struct acpi_device 
*acpi_dev, char *modalias,
  * @size: Size of the buffer.
  *
  * Expose DT compatible modalias as of:NnameTCcompatible.  This function should
- * only be called for devices having PRP0001 in their list of ACPI/PNP IDs.
+ * only be called for devices having ACPI_DT_NAMESPACE_HID in their list of
+ * ACPI/PNP IDs.
  */
 static int create_of_modalias(struct acpi_device *acpi_dev, char *modalias,
  int size)
@@ -980,9 +982,9 @@ static void acpi_device_remove_files(struct acpi_device 
*dev)
  * @adev: ACPI device object to match.
  * @of_match_table: List of device IDs to match against.
  *
- * If @dev has an ACPI companion which has the special PRP0001 device ID in its
- * list of identifiers and a _DSD object with the "compatible" property, use
- * that property to match against the given list of identifiers.
+ * If @dev has an ACPI companion which has ACPI_DT_NAMESPACE_HID in its list of
+ * identifiers and a _DSD object with the "compatible" property, use that
+ * property to match against the given list of identifiers.
  */
 static bool acpi_of_match_device(struct acpi_device *adev,
 const struct of_device_id *of_match_table)
@@ -1038,14 +1040,14 @@ static const struct acpi_device_id *__acpi_match_device(

[linux-yocto] [PATCH 01/11] ACPI / property: Refine consistency check for PRP0001

2016-03-20 Thread weifeng . voon 
From: "Rafael J. Wysocki" 

Refine the check for the presence of the "compatible" property
if the PRP0001 device ID is present in the device's list of
ACPI/PNP IDs to also print the message if _DSD is missing
entirely or the format of it is incorrect.

One special case to take into accout is that the "compatible"
property need not be provided for devices having the PRP0001
device ID in their lists of ACPI/PNP IDs if they are ancestors
of PRP0001 devices with the "compatible" property present.
This is to cover heriarchies of device objects where the kernel
is only supposed to use a struct device representation for the
topmost one and the others represent, for example, functional
blocks of a composite device.

While at it, reduce the log level of the message to "info"
and reduce the log level of the "broken _DSD" message to
"debug" (noise reduction).

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg 
(cherry picked from commit 5c53b262c861dc99aefb215eec579ae438d64fdd)
Signed-off-by: Voon, Weifeng 
---
 drivers/acpi/property.c | 54 -
 include/acpi/acpi_bus.h |  3 ++-
 2 files changed, 33 insertions(+), 24 deletions(-)

diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 0d08373..76075ee 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -79,50 +79,51 @@ static bool acpi_properties_format_valid(const union 
acpi_object *properties)
 static void acpi_init_of_compatible(struct acpi_device *adev)
 {
const union acpi_object *of_compatible;
-   struct acpi_hardware_id *hwid;
-   bool acpi_of = false;
int ret;
 
-   /*
-* Check if the special PRP0001 ACPI ID is present and in that
-* case we fill in Device Tree compatible properties for this
-* device.
-*/
-   list_for_each_entry(hwid, >pnp.ids, list) {
-   if (!strcmp(hwid->id, "PRP0001")) {
-   acpi_of = true;
-   break;
-   }
-   }
-
-   if (!acpi_of)
-   return;
-
ret = acpi_dev_get_property_array(adev, "compatible", ACPI_TYPE_STRING,
  _compatible);
if (ret) {
ret = acpi_dev_get_property(adev, "compatible",
ACPI_TYPE_STRING, _compatible);
if (ret) {
-   acpi_handle_warn(adev->handle,
-"PRP0001 requires compatible 
property\n");
+   if (adev->parent
+   && adev->parent->flags.of_compatible_ok)
+   goto out;
+
return;
}
}
adev->data.of_compatible = of_compatible;
+
+ out:
+   adev->flags.of_compatible_ok = 1;
 }
 
 void acpi_init_properties(struct acpi_device *adev)
 {
struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
+   bool acpi_of = false;
+   struct acpi_hardware_id *hwid;
const union acpi_object *desc;
acpi_status status;
int i;
 
+   /*
+* Check if the special PRP0001 ACPI ID is present and in that case we
+* fill in Device Tree compatible properties for this device.
+*/
+   list_for_each_entry(hwid, >pnp.ids, list) {
+   if (!strcmp(hwid->id, "PRP0001")) {
+   acpi_of = true;
+   break;
+   }
+   }
+
status = acpi_evaluate_object_typed(adev->handle, "_DSD", NULL, ,
ACPI_TYPE_PACKAGE);
if (ACPI_FAILURE(status))
-   return;
+   goto out;
 
desc = buf.pointer;
if (desc->package.count % 2)
@@ -156,13 +157,20 @@ void acpi_init_properties(struct acpi_device *adev)
adev->data.pointer = buf.pointer;
adev->data.properties = properties;
 
-   acpi_init_of_compatible(adev);
-   return;
+   if (acpi_of)
+   acpi_init_of_compatible(adev);
+
+   goto out;
}
 
  fail:
-   dev_warn(>dev, "Returned _DSD data is not valid, skipping\n");
+   dev_dbg(>dev, "Returned _DSD data is not valid, skipping\n");
ACPI_FREE(buf.pointer);
+
+ out:
+   if (acpi_of && !adev->flags.of_compatible_ok)
+   acpi_handle_info(adev->handle,
+"PRP0001 requires 'compatible' property\n");
 }
 
 void acpi_free_properties(struct acpi_device *adev)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 8de4fa9..da07997 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -208,7 +208,8 @@ struct acpi_device_flags {
u32 visited:1;
u32 hotplug_notify:1;
u32 is_dock_station:1;

[linux-yocto] [PATCH 00/11] device property : Backport device property patches to 4.1

2016-03-20 Thread weifeng . voon 
From: "Voon, Weifeng" 

The patch is the "device property" backport for Apollo Lake/Broxton.

Patch "device property: always check for fwnode type" is from mainline.
The other patches is to make sure the patch apply cleanly.

The patches are targeted for linux-yocto-4.1 on standard/base branch.

Alexander Sverdlin (1):
  ACPI / OF: Rename of_node() and acpi_node() to to_of_node() and
to_acpi_node()

Andy Shevchenko (3):
  device property: attach 'else if' to the proper 'if'
  device property: fallback to pset when gettng one string
  device property: always check for fwnode type

Guenter Roeck (1):
  device property: Return -ENXIO if there is no suitable FW interface

Rafael J. Wysocki (5):
  ACPI / property: Refine consistency check for PRP0001
  ACPI / property: Define a symbol for PRP0001
  ACPI / property: Add routine for extraction of _DSD properties
  ACPI / property: Add support for data-only subnodes
  ACPI / property: Extend fwnode_property_* to data-only subnodes

Suthikulpanit, Suravee (1):
  ACPI / scan: Parse _CCA and setup device coherency

 drivers/acpi/Kconfig |   3 +
 drivers/acpi/acpi_platform.c |   2 +-
 drivers/acpi/glue.c  |   5 +
 drivers/acpi/internal.h  |   2 +
 drivers/acpi/property.c  | 359 ++-
 drivers/acpi/scan.c  |  63 ++--
 drivers/base/property.c  |  58 ---
 drivers/gpio/gpiolib.c   |   8 +-
 drivers/leds/leds-gpio.c |   2 +-
 include/acpi/acpi_bus.h  |  68 +++-
 include/linux/acpi.h |  58 +--
 include/linux/fwnode.h   |   1 +
 include/linux/of.h   |   4 +-
 13 files changed, 500 insertions(+), 133 deletions(-)

-- 
1.9.1

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

Re: [yocto] kernel: "devtool modify -x" issue

2016-03-20 Thread Paul Eggleton 
Hi Steve,

FYI the backports just got merged over the weekend.

Cheers,
Paul

On Tue, 15 Mar 2016 09:53:08 Paul Eggleton wrote:
> I hope we are talking a week or less, but I'm not able to give you a
> definitive answer - it depends on patch review and how busy we are dealing
> with issues on the master branch among other things.
> 
> Cheers,
> Paul
> 
> On Mon, 14 Mar 2016 13:49:40 Steve Rae wrote:
> > thanks much...
> > I am very new to this: does "not long though" mean 2-3 days or 2-3 weeks
> > or
> > ???
> > 
> > 
> > On Mon, Mar 14, 2016 at 1:47 PM, Paul Eggleton
> > 
> >  wrote:
> > > Hi Steve,
> > > 
> > > I've just sent out the patches; beyond that it's a matter of the stable
> > > branch testing and integration process. I hope not long though.
> > > 
> > > Cheers,
> > > Paul
> > > 
> > > On Mon, 14 Mar 2016 11:51:08 Steve Rae wrote:
> > >> Paul -- please ETA for getting this into the "jethro" branch.
> > >> Thanks, Steve
> > >> 
> > >> On Fri, Mar 11, 2016 at 10:11 AM, Steve Rae 
> 
> wrote:
> > >> > OK - this seems to build successfully - Thanks!
> > >> > 
> > >> >>> although I still do see the line:
> > >> >  Cloning into '/tmp/devtool6ZA4IK/workdir/source'...
> > >> > 
> > >> > On Thu, Mar 10, 2016 at 7:07 PM, Paul Eggleton
> > >> > 
> > >> >  wrote:
> > >> >> On Fri, 11 Mar 2016 07:55:25 Paul Eggleton wrote:
> > >> >>> On Wed, 09 Mar 2016 10:12:30 Steve Rae wrote:
> > >> >>> > ( using jethro )
> > >> >>> > 
> > >> >>> > I have a 'linux-yocto-custom' layer which builds successfully;
> > >> >>> > then
> > >> >>> > I
> > > 
> > > run:
> > >> >>> > devtool modify -x linux-yocto-custom ../../poky-dev/kernel
> > >> >>> > >> 
> > >> >>> > >> I see a line:
> > >> >>> >   Cloning into '/tmp/devtoolfgiLXr/workdir/source'...
> > >> >>> > 
> > >> >>> > Then I run:
> > >> >>> > devtool build linux-yocto-custom
> > >> >>> > >> 
> > >> >>> > >> it reports the following:
> > >> >>> > Log data follows:
> > >> >>> > | DEBUG: Executing shell function do_kernel_configme
> > >> >>> > | NOTE: kernel configme
> > >> >>> > | [INFO] Configuring target/machine combo: "standard/bcmjava"
> > >> >>> > | [ERROR] frag
> > >> >>> > 
> > >> >>> > /tmp/devtoolfgiLXr/workdir/source/.meta/cfg/scratch/obj/tmp/devto
> > >> >>> > ol
> > >> >>> > fgi
> > >> >>> > LXr/
> > >> >>> > wo rkdir/defconfig does not exist
> > >> >>> > 
> > >> >>> > | [ERROR] No configuration fragments found, this typically is a
> > >> >>> > 
> > >> >>> > misconfigured BSP.
> > >> >>> > 
> > >> >>> > | Check that fragments (or defconfigs) are referenced by
> > >> >>> > | the
> > >> >>> > | board
> > >> >>> > 
> > >> >>> > description.
> > >> >>> > 
> > >> >>> > | config of "standard/bcmjava" failed
> > >> >>> > | WARNING: exit code 1 from a shell command.
> > >> >>> > 
> > >> >>> > which is true, because "devtool modify -x" deletes the temp
> > >> >>> > directory
> > >> >>> > ("/tmp/devtoolfgiLXr") that it used to create this specified
> > >> >>> > workspace
> > >> >>> 
> > >> >>> Hmm, it looks like the temporary path is leaking in somewhere. Is
> > >> >>> there
> > >> >>> an
> > >> >>> easy way I can reproduce this here so I can debug it?
> > >> >> 
> > >> >> Actually I just realised, this task ought not to be running at all -
> > >> >> in
> > >> >> master we've disabled it under these circumsances. There's also one
> > >> >> other fix on master that you'd benefit from in jethro - I've put
> > >> >> them
> > >> >> both on this>>
> > >> >> 
> > >> >> contrib branch:
> > >> >>   http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=paul
> > >> >>   e/
> > >> >>   jet
> > >> >>   hro-fixes4>>
> > >> >> 
> > >> >> If you could let me know how it works for you that would be great;
> > >> >> I'll
> > >> >> send it out soon.
> > >> >> 
> > >> >> Cheers,
> > >> >> Paul
> > >> >> 
> > >> >> --
> > >> >> 
> > >> >> Paul Eggleton
> > >> >> Intel Open Source Technology Centre
> > > 
> > > --
> > > 
> > > Paul Eggleton
> > > Intel Open Source Technology Centre

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-panel-2][PATCH] showdesktop: Make sure active state is initialized

2016-03-20 Thread Jussi Kukkonen 
There are cases (in qemu at least) where set_active()
is never called on startup. Make sure we initialize the active
state so the icon gets loaded and the applet is not confused
about the current state.

Signed-off-by: Jussi Kukkonen 
---
 applets/showdesktop/showdesktop.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/applets/showdesktop/showdesktop.c 
b/applets/showdesktop/showdesktop.c
index 61dd5c2..33c13e1 100644
--- a/applets/showdesktop/showdesktop.c
+++ b/applets/showdesktop/showdesktop.c
@@ -181,6 +181,12 @@ button_clicked_cb (GtkButton *button,
);
 }
 
+static void
+realize_cb (GtkWidget *button, ShowDesktopApplet *applet)
+{
+sync_applet (applet);
+}
+
 G_MODULE_EXPORT GtkWidget *
 mb_panel_applet_create (const char*id,
 GtkOrientation orientation)
@@ -216,6 +222,10 @@ mb_panel_applet_create (const char*id,
   "clicked",
   G_CALLBACK (button_clicked_cb),
   applet);
+g_signal_connect (button,
+  "realize",
+  G_CALLBACK (realize_cb),
+  applet);
 
 g_object_weak_ref (G_OBJECT (button),
(GWeakNotify) show_desktop_applet_free,
-- 
2.7.0

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

Re: [yocto] Re: Qt5.6 new modules

2016-03-20 Thread Christian Ege 
Hi,

2016-03-17 17:16 GMT+01:00 idealsim :
> Hi, i have started a build of the image this master Branch, like you said i
> have an error on qtserialbus :
>
> WARNING: Failed to fetch URL
> git://github.com/qtproject/qtserialbus.git;name=qtserialbus;branch=5.6;protocol=git,
> attempting MIRRORS if available
> ERROR: Fetcher failure: Unable to find revision
> 6a16281aceedb713676e16c3074e6f7ea1e70b79 in branch 5.6 even from upstream
> ERROR: Function failed: Fetcher failure for URL:
> 'git://github.com/qtproject/qtserialbus.git;name=qtserialbus;branch=5.6;protocol=git'.
> Unable to fetch URL from any source.
> ERROR: Logfile of failure stored in:
> /media/modjo/data1TO/yocto/seco/udoo-community-bsp/neoBuild/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtserialbus/5.5.99+5.6.0-rc+gitAUTOINC+6a16281ace-r0/temp/log.do_fetch.5862
> ERROR: Task 894
> (/media/modjo/data1TO/yocto/seco/udoo-community-bsp/sources/meta-qt5/recipes-qt/qt5/qtserialbus_git.bb,
> do_fetch) failed with exit code '1'
>
> This is my qtserialbus_git.bb :
>
> require qt5.inc
> require qt5-git.inc
>
> # There are no LGPLv3-only licensed files in this component.
> # There are no GPLv2 licensed files in this component.
> LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 & The-Qt-Company-Qt-LGPL-Exception-1.1
> | LGPL-3.0)"
> LIC_FILES_CHKSUM = " \
> file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \
> file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \
> file://LICENSE.FDL;md5=6d9f2a9af4c8b8c3c769f6cc1b6aaf7e \
> file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \
> "
>
> DEPENDS += "qtbase qtserialport"
>
> SRCREV = "6a16281aceedb713676e16c3074e6f7ea1e70b79"
The SRCREV is the git SHA1 of the repository qtserialbus. For the 5.6
Branch the latest one is:

SRCREV = "92c979c6652d55c30ab9118d45db74d8da96fc3b"


You can check the SHA1s here:
https://github.com/qtproject/qtserialbus/commits/5.6

The MD5 Sums will be complained during configure step and bitbake wil
tell you the right ones.
Please check if the Licences do match

Regards,
Christian

>
> An idea is welcome !
>
> Regards,
>
> Mickaël
>
>
>
> Le 16/03/2016 14:57, idealsim a écrit :
>
> Thanks for the tip. I will try it out and let you know ...
>
> Regards,
>
> Mickaël
>
> Le 16/03/2016 10:17, Christian Ege a écrit :
>
> Hi,,
>
> 2016-03-16 9:04 GMT+01:00 idealsim :
>
> Hi, we have build an image for udoo neo from meta-qt5 jansa/master-5.6 and
> works fine (thanks to Christian Ege ). The problem is that I'm looking for
> https://github.com/qtproject/qtquickcontrols2 and
> https://github.com/qtproject/qtserialbus. My question is how we can add this
> modules to our build ?  I add this to our local.conf :
>
>  "qtquickcontrols2 \
>   qtserialbus \
>  "
> But this modules don't have buildable providers ! If someone can help to
> said me how to proceed ...
>
> You can try to add a meta-qt5/recipes-qt/qt5/qtserialbus_git.bb and
> take for example meta-qt5/recipes-qt/qt5/qtsensors_git.bb as reference
>
> require qt5.inc
> require qt5-git.inc
> # There are no LGPLv3-only licensed files in this component.
> # There are no GPLv2 licensed files in this component.
> LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 &
> The-Qt-Company-Qt-LGPL-Exception-1.1 | LGPL-3.0)"
> LIC_FILES_CHKSUM = " \
> file://LICENSE.LGPLv21;md5=58a180e1cf84c756c29f782b3a485c29 \
> file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \
> file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \
> file://LGPL_EXCEPTION.txt;md5=9625233da42f9e0ce9d63651a9d97654 \
> file://LICENSE.FDL;md5=6d9f2a9af4c8b8c3c769f6cc1b6aaf7e \
> file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \
> "
> DEPENDS += "qtbase"
>
> SRCREV = "71a323e1f12df8d213a4052621027e223eb5a343"
>
> The configure step will bail out due to the fact that you have wrong
> checksums but it will show you the right ones
>
> Best,
> Christian
>
>
> regards,
>
> Mickael
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
>
>



-- 
http://ch.ege.io/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [matchbox-wm][PATCH] ewmh: Fix data type of a few XChangeProperty calls

2016-03-20 Thread Jussi Kukkonen 
XChangeProperty documentation: "If the specified format is 32, the
property data must be a long array."

Using int can lead to bogus data being used on platforms where long
actually is different from int.

Signed-off-by: Jussi Kukkonen 
---

Yocto-specific reference: Sato does not really use the other cases
but _NET_SHOW_DESKTOP corruption lead to problems like [YOCTO #9284]
and [YOCTO #9026].

 src/ewmh.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/ewmh.c b/src/ewmh.c
index 31ac969..a736037 100644
--- a/src/ewmh.c
+++ b/src/ewmh.c
@@ -136,7 +136,7 @@ ewmh_init(Wm *w)
 void
 ewmh_init_props(Wm *w)
 {
-  int num_desktops = 1;
+  long num_desktops = 1;
   
   set_compliant(w);
   set_supported(w);
@@ -455,15 +455,18 @@ ewmh_update_lists(Wm *w)
   */
   if (w->config->super_modal)
 {
+  long modals = w->n_modals_present;
+  long modal_blockers = w->n_modal_blocker_wins;
+
   XChangeProperty(w->dpy, w->root, 
  w->atoms[_MB_NUM_MODAL_WINDOWS_PRESENT],
  XA_CARDINAL, 32, PropModeReplace,
- (unsigned char *)>n_modals_present, 1);
+ (unsigned char *), 1);
 
   XChangeProperty(w->dpy, w->root, 
  w->atoms[_MB_NUM_SYSTEM_MODAL_WINDOWS_PRESENT],
  XA_CARDINAL, 32, PropModeReplace,
- (unsigned char *)>n_modal_blocker_wins, 1);
+ (unsigned char *)_blockers, 1);
 }
 }
 
@@ -472,7 +475,7 @@ ewmh_update_desktop_hint(Wm *w)
 {
/* Desktop showing hint */
 
-   int val = (w->flags & DESKTOP_RAISED_FLAG) ? 1 : 0;
+   long val = (w->flags & DESKTOP_RAISED_FLAG) ? 1 : 0;
 
XChangeProperty(w->dpy, w->root, w->atoms[_NET_SHOW_DESKTOP],
   XA_CARDINAL, 32, PropModeReplace, 
-- 
2.7.0

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

Re: [yocto] Possible introspection failure in master

2016-03-20 Thread Chris Tapp 

> On 18 Mar 2016, at 18:59, alexander.kana...@linux.intel.com wrote:
> 
>> The gstreamer _git recipes have not been updated to include the
>> gobject introspection patches which were applied to the 1.6.3 recipes.
> 
> Yeah, I forgot about the git recipes, as they're totally hidden from
> default builds. I'll get them fixed.

Thanks - I’ll try and keep an eye open so I can have a look once the changes 
are available.

> 
>> Try disabling gobject introspection via DISTRO or MACHINE features, ie:
>> 
>>  MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
>> gobject-introspection-data"
> 
> That is not going to help, I'm afraid. The recipes need further custom
> fixing even when introspection is disabled.
> 
> Alex

--

Chris Tapp
opensou...@keylevel.com
www.keylevel.com


You can tell you're getting older when your car insurance gets real cheap!

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

Re: [yocto] Installing the SDKs made with meta-mingw

2016-03-20 Thread Matt Hoosier 
On Thu, Mar 17, 2016 at 10:48 AM, Christopher Larson 
wrote:

>
>
> On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson 
> wrote:
>
>> On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier 
>> wrote:
>>
>>> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier 
>>> wrote:
>>>


 On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson <
 clar...@kergoth.com> wrote:

> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier 
> wrote:
>
>> I've successfully built a Canadian-cross SDK using the meta-mingw
>> layer. Very nice!
>>
>> Because the layer lobotomizes the SDK_PACKAGING_FUNC when
>> ${SDKMACHINE} is set to a MinGW host, though, the resulting SDK is not
>> encapsulated into the self-extracting tarball and the corresponding
>> relocation logic (relocate_sdk.py and so forth) is omitted.
>>
>> Any suggestions on how to do the last-mile work to use the SDK on
>> Windows? Or perhaps nothing is needed at all, except adjusting the 
>> prefixes
>> built into environment-setup-? Although that would be nice, I
>> think at least some installation-time adjustment is necessary though; 
>> when
>> I do:
>>
>> arm-poky-linux-gnueabi-gcc -o foo foo.c
>> --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>
>> , the following happens during linking:
>>
>> ld.exe: cannot find /lib/libc.so.6 inside
>> d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>
>
 As it turns out, the immediate error here was simply that libc.so.6 did
 not exist, so ld.exe was telling the truth in this case. The symbolic links
 stored in the SDK tarball that would have created libc.so.6 aren't
 meaningful on Windows, so tar just ignores them when unpacking. Presumably
 some fancier handling of the tarball unpacking to simulate symlinks by
 making copies of the pointed-to file would cure this.


>
> Mark Hatle's branch switches to batch files for environment setup and
> whatnot. I don't know if it addresses the reloc issue or not, but it's a
> substantial improvement over master. See
> https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw
>

 Thanks, I'll try that.

>>>
>>> Mark Hatle's branch does work much more nicely for that. There's still
>>> the problem of what to do with the symlink from the SDK tarballs. Are there
>>> any regular users of these mingw SDKs out there who know the right
>>> expectation on how to extract them?
>>>
>>
>> tar has an option to resolve symlinks to the files, I'd expect you could
>> just add that to the variable for the tar options for the sdk, and it'd
>> just duplicate the symlinks. You'll have extra files, so it'd be larger,
>> but at least it'd be functional.
>>
>
> Erm, I meant duplicate the files, not the symlinks :) The symlinks would
> be resolved to files. Clearly I haven't had enough caffeine yet today.
>

Thanks.

If you're thinking of "tar -h -xf ... ", I'd given that a try prior to my
previous message. It doesn't seem to have any effect on the outcome (at
least, for the copy of 'tar' bundled into my installation of MinGW and
MSys).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto