Re: [linux-yocto] [PATCH 0/2] Fix standard/base pollution

2016-09-30 Thread Bruce Ashfield

On 2016-09-30 5:32 PM, Cal Sullivan wrote:



On 09/30/2016 01:51 PM, Bruce Ashfield wrote:

On 2016-09-30 4:46 PM, California Sullivan wrote:

Hi Bruce, Saul,

A while back before we created the standard/intel/base branches some
patches that were not appropriate for standard/base were merged into
the branch and caused bug [YOCTO #9587]. This patch set aims to fix
that.

The first patch reverts the inappropriate patches in standard/base. The
second patch reverts the revert and is intended for standard/intel/base
after the first revert patch waterfalls into it.

I know this is kind of kludgey but I believe its the right thing to do.

Let me know if you think otherwise.


I can do the individual reverts, rather than via a single patch. Just
provide the commit IDs (which you did in your email, so that is fine).

I can then apply those same changes to standard/intel/base again. That
way we keep a 1:1 commit granularity.

If git objects, I can go the route of these patches :D

Bruce



That will work!

I forgot to mention, this is intended for the 4.1 tree. The 4.4 tree has
more inappropriate patches and their order matters. Here are the commit
IDs in an order that reverted cleanly for me:

4086f8c349569926fd8fbe967ec24bdeabc79f95
0148b3601f29b159b4f84c1478ff1859bbd48efe
08943f2bbd507f8b7f5ef101ccc4755cbec79aad
a517d5b72e764ec22f0055edeb685c102051239e
cd83f4095b234652ae65321f35700f7e3441f0f9


I was able to do the reverts for 4.1 and 4.4 in standard/base and then
cherry pick the same commits back into standard/intel/base,
standard/preempt-rt/intel/base and standard/tiny/intel/base

This is along with some -stable updates that I have staged, so we'll
need those to get these changes.

If anything is broken, send patches or exact sequences of commits to
revert/cherry-pick.

Cheers,

Bruce



Thanks,
Cal



Thanks,
Cal

California Sullivan (2):
  Revert Upstream-status: Inappropriate commits in standard/base
  Reapply Upstream-status: Inappropriate commits removed from
standard/base








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


Re: [linux-yocto] [PATCH 0/2] Fix standard/base pollution

2016-09-30 Thread Cal Sullivan



On 09/30/2016 01:51 PM, Bruce Ashfield wrote:

On 2016-09-30 4:46 PM, California Sullivan wrote:

Hi Bruce, Saul,

A while back before we created the standard/intel/base branches some
patches that were not appropriate for standard/base were merged into
the branch and caused bug [YOCTO #9587]. This patch set aims to fix
that.

The first patch reverts the inappropriate patches in standard/base. The
second patch reverts the revert and is intended for standard/intel/base
after the first revert patch waterfalls into it.

I know this is kind of kludgey but I believe its the right thing to do.

Let me know if you think otherwise.


I can do the individual reverts, rather than via a single patch. Just
provide the commit IDs (which you did in your email, so that is fine).

I can then apply those same changes to standard/intel/base again. That
way we keep a 1:1 commit granularity.

If git objects, I can go the route of these patches :D

Bruce



That will work!

I forgot to mention, this is intended for the 4.1 tree. The 4.4 tree has 
more inappropriate patches and their order matters. Here are the commit 
IDs in an order that reverted cleanly for me:


4086f8c349569926fd8fbe967ec24bdeabc79f95
0148b3601f29b159b4f84c1478ff1859bbd48efe
08943f2bbd507f8b7f5ef101ccc4755cbec79aad
a517d5b72e764ec22f0055edeb685c102051239e
cd83f4095b234652ae65321f35700f7e3441f0f9

Thanks,
Cal



Thanks,
Cal

California Sullivan (2):
  Revert Upstream-status: Inappropriate commits in standard/base
  Reapply Upstream-status: Inappropriate commits removed from
standard/base






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


Re: [linux-yocto] [PATCH 0/2] Fix standard/base pollution

2016-09-30 Thread Bruce Ashfield

On 2016-09-30 4:46 PM, California Sullivan wrote:

Hi Bruce, Saul,

A while back before we created the standard/intel/base branches some
patches that were not appropriate for standard/base were merged into
the branch and caused bug [YOCTO #9587]. This patch set aims to fix
that.

The first patch reverts the inappropriate patches in standard/base. The
second patch reverts the revert and is intended for standard/intel/base
after the first revert patch waterfalls into it.

I know this is kind of kludgey but I believe its the right thing to do.

Let me know if you think otherwise.


I can do the individual reverts, rather than via a single patch. Just
provide the commit IDs (which you did in your email, so that is fine).

I can then apply those same changes to standard/intel/base again. That
way we keep a 1:1 commit granularity.

If git objects, I can go the route of these patches :D

Bruce



Thanks,
Cal

California Sullivan (2):
  Revert Upstream-status: Inappropriate commits in standard/base
  Reapply Upstream-status: Inappropriate commits removed from
standard/base




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


[linux-yocto] [PATCH 2/2] Reapply Upstream-status: Inappropriate commits removed from standard/base

2016-09-30 Thread California Sullivan
While these are not appropriate for standard/base, they are OK for
standard/intel/base.

Signed-off-by: California Sullivan 
---
 drivers/gpio/gpio-pca953x.c  |   44 +-
 drivers/spi/spi-pxa2xx-pci.c |1 +
 include/DSDT.hex | 1191 ++
 3 files changed, 1229 insertions(+), 7 deletions(-)
 create mode 100644 include/DSDT.hex

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 30798bb..fad258e 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -80,12 +80,6 @@ static const struct i2c_device_id pca953x_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, pca953x_id);
 
-static const struct acpi_device_id pca953x_acpi_ids[] = {
-   { "INT3491", 16 | PCA953X_TYPE | PCA_INT, },
-   { }
-};
-MODULE_DEVICE_TABLE(acpi, pca953x_acpi_ids);
-
 #define MAX_BANK 5
 #define BANK_SZ 8
 
@@ -112,6 +106,35 @@ struct pca953x_chip {
unsigned long driver_data;
 };
 
+struct pca953x_info {
+   kernel_ulong_t driver_data;
+   void (*setup)(struct pca953x_chip *chip);
+};
+
+static void pca953x_setup_int3491(struct pca953x_chip *chip)
+{
+   struct acpi_device *adev = ACPI_COMPANION(>client->dev);
+   unsigned int uid;
+
+   if (kstrtouint(acpi_device_uid(adev), 0, ) || !uid--)
+   return;
+
+   chip->gpio_start = 8 /* sch_gpio */ +
+  8 /* gpio-dwapb */ +
+ 16 /* pca9535 */ * uid;
+}
+
+static const struct pca953x_info pca953x_info_int3491 = {
+   .driver_data = 16 | PCA953X_TYPE | PCA_INT,
+   .setup = pca953x_setup_int3491,
+};
+
+static const struct acpi_device_id pca953x_acpi_ids[] = {
+   { "INT3491",  (kernel_ulong_t)_info_int3491 },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, pca953x_acpi_ids);
+
 static inline struct pca953x_chip *to_pca(struct gpio_chip *gc)
 {
return container_of(gc, struct pca953x_chip, gpio_chip);
@@ -723,12 +746,19 @@ static int pca953x_probe(struct i2c_client *client,
chip->driver_data = id->driver_data;
} else {
const struct acpi_device_id *id;
+   const struct pca953x_info *info;
 
id = acpi_match_device(pca953x_acpi_ids, >dev);
if (!id)
return -ENODEV;
 
-   chip->driver_data = id->driver_data;
+   info = (struct pca953x_info *)id->driver_data;
+   if (!info)
+   return -ENODEV;
+
+   chip->driver_data = info->driver_data;
+   if (info->setup)
+   info->setup(chip);
}
 
chip->chip_type = PCA_CHIP_TYPE(chip->driver_data);
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index d19d7f2..562ffc1 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -169,6 +169,7 @@ static int pxa2xx_spi_pci_probe(struct pci_dev *dev,
memset(, 0, sizeof(pi));
pi.parent = >dev;
pi.name = "pxa2xx-spi";
+   pi.fwnode = dev->dev.fwnode;
pi.id = ssp->port_id;
pi.data = _pdata;
pi.size_data = sizeof(spi_pdata);
diff --git a/include/DSDT.hex b/include/DSDT.hex
new file mode 100644
index 000..b1e2960
--- /dev/null
+++ b/include/DSDT.hex
@@ -0,0 +1,1191 @@
+/*
+ * Copyright (c) 2013 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice, 
this
+ * list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 
USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * 
+ * Intel ACPI Component Architecture
+ * ASL+ Optimizing Compiler version 20150515-64
+ * Copyright (c) 2000 - 2015 Intel Corporation
+ * 
+ * Compilation of "dsdt-fixed-spi.dsl" - Wed Sep 23 12:49:37 2015
+ * 
+ * C source code 

[linux-yocto] [PATCH 1/2] Revert Upstream-status: Inappropriate commits in standard/base

2016-09-30 Thread California Sullivan
This reverts the following commits:

* c39f26cd "acpi: added a custom DSDT file."
* 94bfb66b "gpio: pca953x: provide GPIO base based on _UID"
* 2fb3159a "spi-pxa2xx: fixed ACPI-based enumeration of SPI devices."

Signed-off-by: California Sullivan 
---
 drivers/gpio/gpio-pca953x.c  |   44 +-
 drivers/spi/spi-pxa2xx-pci.c |1 -
 include/DSDT.hex | 1191 --
 3 files changed, 7 insertions(+), 1229 deletions(-)
 delete mode 100644 include/DSDT.hex

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index fad258e..30798bb 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -80,6 +80,12 @@ static const struct i2c_device_id pca953x_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, pca953x_id);
 
+static const struct acpi_device_id pca953x_acpi_ids[] = {
+   { "INT3491", 16 | PCA953X_TYPE | PCA_INT, },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, pca953x_acpi_ids);
+
 #define MAX_BANK 5
 #define BANK_SZ 8
 
@@ -106,35 +112,6 @@ struct pca953x_chip {
unsigned long driver_data;
 };
 
-struct pca953x_info {
-   kernel_ulong_t driver_data;
-   void (*setup)(struct pca953x_chip *chip);
-};
-
-static void pca953x_setup_int3491(struct pca953x_chip *chip)
-{
-   struct acpi_device *adev = ACPI_COMPANION(>client->dev);
-   unsigned int uid;
-
-   if (kstrtouint(acpi_device_uid(adev), 0, ) || !uid--)
-   return;
-
-   chip->gpio_start = 8 /* sch_gpio */ +
-  8 /* gpio-dwapb */ +
- 16 /* pca9535 */ * uid;
-}
-
-static const struct pca953x_info pca953x_info_int3491 = {
-   .driver_data = 16 | PCA953X_TYPE | PCA_INT,
-   .setup = pca953x_setup_int3491,
-};
-
-static const struct acpi_device_id pca953x_acpi_ids[] = {
-   { "INT3491",  (kernel_ulong_t)_info_int3491 },
-   { }
-};
-MODULE_DEVICE_TABLE(acpi, pca953x_acpi_ids);
-
 static inline struct pca953x_chip *to_pca(struct gpio_chip *gc)
 {
return container_of(gc, struct pca953x_chip, gpio_chip);
@@ -746,19 +723,12 @@ static int pca953x_probe(struct i2c_client *client,
chip->driver_data = id->driver_data;
} else {
const struct acpi_device_id *id;
-   const struct pca953x_info *info;
 
id = acpi_match_device(pca953x_acpi_ids, >dev);
if (!id)
return -ENODEV;
 
-   info = (struct pca953x_info *)id->driver_data;
-   if (!info)
-   return -ENODEV;
-
-   chip->driver_data = info->driver_data;
-   if (info->setup)
-   info->setup(chip);
+   chip->driver_data = id->driver_data;
}
 
chip->chip_type = PCA_CHIP_TYPE(chip->driver_data);
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index 562ffc1..d19d7f2 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -169,7 +169,6 @@ static int pxa2xx_spi_pci_probe(struct pci_dev *dev,
memset(, 0, sizeof(pi));
pi.parent = >dev;
pi.name = "pxa2xx-spi";
-   pi.fwnode = dev->dev.fwnode;
pi.id = ssp->port_id;
pi.data = _pdata;
pi.size_data = sizeof(spi_pdata);
diff --git a/include/DSDT.hex b/include/DSDT.hex
deleted file mode 100644
index b1e2960..000
--- a/include/DSDT.hex
+++ /dev/null
@@ -1,1191 +0,0 @@
-/*
- * Copyright (c) 2013 Intel Corporation. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- *
- * 1. Redistributions of source code must retain the above copyright notice, 
this
- * list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright notice,
- * this list of conditions and the following disclaimer in the documentation
- * and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
IMPLIED
- * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
- * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
- * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
- * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY,
- * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 
USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-/*
- * 
- * Intel ACPI Component Architecture
- * ASL+ Optimizing Compiler version 20150515-64
- * Copyright (c) 

[linux-yocto] [PATCH 0/2] Fix standard/base pollution

2016-09-30 Thread California Sullivan
Hi Bruce, Saul,

A while back before we created the standard/intel/base branches some
patches that were not appropriate for standard/base were merged into
the branch and caused bug [YOCTO #9587]. This patch set aims to fix
that.

The first patch reverts the inappropriate patches in standard/base. The
second patch reverts the revert and is intended for standard/intel/base
after the first revert patch waterfalls into it.

I know this is kind of kludgey but I believe its the right thing to do.

Let me know if you think otherwise.

Thanks,
Cal

California Sullivan (2):
  Revert Upstream-status: Inappropriate commits in standard/base
  Reapply Upstream-status: Inappropriate commits removed from
standard/base


-- 
2.5.5

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


Re: [linux-yocto] [PATCH 5/5] meta/common-pc-64: use mmc-sdhci feature

2016-09-30 Thread Bruce Ashfield

On 2016-09-29 11:07 AM, Alejandro Hernandez wrote:



On 09/29/2016 12:40 AM, Bruce Ashfield wrote:

On 09/28/2016 04:04 PM, Alejandro Hernandez wrote:



On 09/28/2016 01:45 PM, Bruce Ashfield wrote:

On 09/27/2016 12:48 PM, Alejandro Hernandez wrote:

Signed-off-by: Alejandro Hernandez

---
  bsp/common-pc-64/common-pc-64.scc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/bsp/common-pc-64/common-pc-64.scc
b/bsp/common-pc-64/common-pc-64.scc
index 5737a83..f5a3076 100644
--- a/bsp/common-pc-64/common-pc-64.scc
+++ b/bsp/common-pc-64/common-pc-64.scc
@@ -10,6 +10,7 @@ include cfg/x86_64.scc
  include cfg/amd.scc
  include cfg/intel.scc
  include features/pci/pci.scc
+include features/mmc/mmc-sdhci.scc


Rather than including this here, and inflicting the extra build/modules
on everyone that uses the common-pc baseline, wouldn't it be better if
the BSPs that need this support included it directly ?

On that topic, what sorts of platforms and use cases need this ? If it
is a broad set of platforms, then adding it in common-pc makes sense ..

Bruce


I agree, in this case genericx86 and genericx86-64 should include mmc
support, is there a better place to add this for this scenario?


Hmmm. That is the problem, genericx86* map directly to common-pc, so
they are fundamentally the same thing.

The only way to make it optional for boards like that is to use
KERNEL_FEATURES_genericx86_append .. and then list the features.

We could do this if necessary, I wouldn't mind.


But we don't necessarily have to go that way, if we just cover what
mmc devices are being used, and what use case they are covering
(i.e. are these common parts that are being used for storage ?
boot ? .. something else ?).


In this case, trying to install the system on an SD card using either
genericx86
or genericx86-64 fails since the SD card is not detected, on a booted
system
the SD card is unavailable to use as storage as well.

While I believe that using it as storage is important, I think that
installing the system
on an SD card is a feature that should be provided.


I can live with that as well.

In the interest of getting this into the tree for the upcoming
release, I can merge this as is, and we can revisit if there are
issues with the size of the kernel (or runtime, etc).

Bruce



Since as I said, if they are common and the use case is valid, we
can just turn them on in common-pc.

Bruce



Alejandro



  include features/usb/ehci-hcd.scc
  include features/usb/uhci-hcd.scc
  include features/usb/ohci-hcd.scc











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