* [PATCH 7/9] dmaengine: ti-dma-crossbar: Correct type for of_find_property() third parameter
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
The correct type is int and not for the third parameter of
of_find_property().
Fixes compilation for 64bit architectures (x86_64, aarch64).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 5ae294b256a7..e4f3bd1ae264 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -311,7 +311,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
struct property *prop;
struct resource *res;
u32 safe_val;
- size_t sz;
+ int sz;
void __iomem *iomem;
int i, ret;
--
2.10.0
^ permalink raw reply related
* [PATCH 6/9] dmaengine: omap-dma: enable COMPILE_TEST
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
To get more coverage, enable COMPILE_TEST for this driver.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 4348249b943a..84647d6cb2f4 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -130,7 +130,7 @@ config DMA_JZ4780
config DMA_OMAP
tristate "OMAP DMA support"
- depends on ARCH_OMAP
+ depends on ARCH_OMAP || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
select TI_DMA_CROSSBAR if SOC_DRA7XX
--
2.10.0
^ permalink raw reply related
* [PATCH 5/9] dmaengine/ARM: omap-dma: Fix the DMAengine compile test on non OMAP configs
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
The DMAengine driver for omap-dma use three function calls from the
plat-omap legacy driver. When the DMAengine driver is built when ARCH_OMAP
is not set, the compilation will fail due to missing symbols.
Add empty inline functions to allow the DMAengine driver to be compiled
with COMPILE_TEST.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
include/linux/omap-dma.h | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 1d99b61adc65..290081620b3e 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -297,6 +297,7 @@ struct omap_system_dma_plat_info {
#define dma_omap15xx() __dma_omap15xx(d)
#define dma_omap16xx() __dma_omap16xx(d)
+#if defined(CONFIG_ARCH_OMAP)
extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
@@ -355,4 +356,22 @@ static inline int omap_lcd_dma_running(void)
}
#endif
+#else /* CONFIG_ARCH_OMAP */
+
+static inline struct omap_system_dma_plat_info *omap_get_plat_info(void)
+{
+ return NULL;
+}
+
+static inline int omap_request_dma(int dev_id, const char *dev_name,
+ void (*callback)(int lch, u16 ch_status, void *data),
+ void *data, int *dma_ch)
+{
+ return -ENODEV;
+}
+
+static inline void omap_free_dma(int ch) { }
+
+#endif /* CONFIG_ARCH_OMAP */
+
#endif /* __LINUX_OMAP_DMA_H */
--
2.10.0
^ permalink raw reply related
* [PATCH 4/9] dmaengine: edma: enable COMPILE_TEST
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
To get more coverage, enable COMPILE_TEST for this driver.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index fe2dbb811e19..4348249b943a 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -515,7 +515,7 @@ config TI_DMA_CROSSBAR
config TI_EDMA
bool "TI EDMA support"
- depends on ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE
+ depends on ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
select TI_DMA_CROSSBAR if ARCH_OMAP
--
2.10.0
^ permalink raw reply related
* [PATCH 3/9] dmaengine: edma: Use correct type for of_find_property() third parameter
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
The correct type is int and not for the third parameter of
of_find_property().
Fixes compilation for 64bit architectures (x86_64, aarch64).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/edma.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 4c8818278fcc..16c0bb92fa4d 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2024,8 +2024,7 @@ static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev,
{
struct edma_soc_info *info;
struct property *prop;
- size_t sz;
- int ret;
+ int sz, ret;
info = devm_kzalloc(dev, sizeof(struct edma_soc_info), GFP_KERNEL);
if (!info)
--
2.10.0
^ permalink raw reply related
* [PATCH 2/9] dmaengine: edma: Use enum for eDMA binding type (legacy vs TPCC)
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
Fixes the following warning when compiling the driver for 64bit
architectures (x86_64 for example):
drivers/dma/edma.c:2185:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (match && (u32)match->data == EDMA_BINDING_TPCC)
^
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/edma.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index c2098a4b4dcf..4c8818278fcc 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -261,8 +261,11 @@ static const struct edmacc_param dummy_paramset = {
.ccnt = 1,
};
-#define EDMA_BINDING_LEGACY 0
-#define EDMA_BINDING_TPCC 1
+enum edma_binding_type {
+ EDMA_BINDING_LEGACY = 0,
+ EDMA_BINDING_TPCC,
+};
+
static const struct of_device_id edma_of_ids[] = {
{
.compatible = "ti,edma3",
@@ -2184,7 +2187,8 @@ static int edma_probe(struct platform_device *pdev)
const struct of_device_id *match;
match = of_match_node(edma_of_ids, node);
- if (match && (u32)match->data == EDMA_BINDING_TPCC)
+ if (match &&
+ (enum edma_binding_type)match->data == EDMA_BINDING_TPCC)
legacy_mode = false;
info = edma_setup_info_from_dt(dev, legacy_mode);
--
2.10.0
^ permalink raw reply related
* [PATCH 1/9] dmaengine: edma: Add missing MODULE_DEVICE_TABLE() for of_device_id structs
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
The MODULE_DEVICE_TABLE() were missing from the driver for the of_device_id
structures.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/edma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 3d277fa76c1a..c2098a4b4dcf 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -274,11 +274,13 @@ static const struct of_device_id edma_of_ids[] = {
},
{}
};
+MODULE_DEVICE_TABLE(of, edma_of_ids);
static const struct of_device_id edma_tptc_of_ids[] = {
{ .compatible = "ti,edma3-tptc", },
{}
};
+MODULE_DEVICE_TABLE(of, edma_tptc_of_ids);
static inline unsigned int edma_read(struct edma_cc *ecc, int offset)
{
--
2.10.0
^ permalink raw reply related
* [PATCH 0/9] dmaengine: ti drivers: enable COMPILE_TESTing
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The following series will enable unconditional COMPILE_TEST coverage for the
following drivers: omap-dma, edma and ti-dma-crossbar
The series includes fixes noticed when compiling the drivers for x86_64 and
aarch64.
Replaces the patch Vinod sent to enable partial compile testing for omap-dma:
http://www.spinics.net/lists/dmaengine/msg11025.html
Regards,
Peter
---
Peter Ujfalusi (9):
dmaengine: edma: Add missing MODULE_DEVICE_TABLE() for of_device_id
structs
dmaengine: edma: Use enum for eDMA binding type (legacy vs TPCC)
dmaengine: edma: Use correct type for of_find_property() third
parameter
dmaengine: edma: enable COMPILE_TEST
dmaengine/ARM: omap-dma: Fix the DMAengine compile test on non OMAP
configs
dmaengine: omap-dma: enable COMPILE_TEST
dmaengine: ti-dma-crossbar: Correct type for of_find_property() third
parameter
dmaengine: ti-dma-crossbar: Use enum for crossbar type
dmaengine: ti-dma-crossbar: enable COMPILE_TEST
drivers/dma/Kconfig | 8 ++++----
drivers/dma/edma.c | 15 ++++++++++-----
drivers/dma/ti-dma-crossbar.c | 12 +++++++-----
include/linux/omap-dma.h | 19 +++++++++++++++++++
4 files changed, 40 insertions(+), 14 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH v3 2/2] ARM: exynos_defconfig: Remove old non-working MIPI driver
From: Krzysztof Kozlowski @ 2016-09-16 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474014760-23173-1-git-send-email-k.kozlowski@samsung.com>
The Exynos MIPI driver does not work anymore (it is board file only) so
it is removed. Remove also config options.
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Donghwa Lee <dh09.lee@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
This does not really depend on patch #1. The driver is dysfunctional and
it does not work so defconfig change can be applied separately.
Changes since v2:
1. Remove also EXYNOS_MIPI_DSI, pointed out by Tomi Valkeinen.
Changes since v1:
1. New patch.
---
arch/arm/configs/exynos_defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index 4e484f406419..c58f6841f8aa 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -168,8 +168,6 @@ CONFIG_DRM_PANEL_SAMSUNG_LD9040=y
CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=y
CONFIG_DRM_NXP_PTN3460=y
CONFIG_DRM_PARADE_PS8622=y
-CONFIG_EXYNOS_VIDEO=y
-CONFIG_EXYNOS_MIPI_DSI=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
CONFIG_BACKLIGHT_PWM=y
--
1.9.1
^ permalink raw reply related
* v4.8-rc: GSM audio causes trouble
From: Pavel Machek @ 2016-09-16 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915205142.GA6747@amd>
On Thu 2016-09-15 22:51:42, Pavel Machek wrote:
> Hi!
>
> > I was trying to improve GSM call quality, and hit problems in
> > v4.8-rc. Sound only worked for a while, then I tried to kill
> > cmtspeech_ofono_test, and could not, not even with -9 and could not
> > even reboot.
> >
> > I went back to v4.1 (ok, quite far, I see), and problems are gone.
> >
> > Does it work for you? Any ideas what to try... besides bisect?
>
> v4.7 is okay.
>
> v4.8 with
>
> git diff ..mini-v4.7 drivers/hsi/ | git apply
I believe I tried just reverting
9c99e5e51988798af2a687ef9b1716dd79388550 before, but that did not
help.
I guess I'll try with these reverted, next:
pavel at amd:/data/l/linux-n900$ git show
9c99e5e51988798af2a687ef9b1716dd79388550 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
ad60db2f9fe3367e60a21fc0afe19999516f8b27 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
4e552310cdf0c81210b5fc9173f7cf497eeb9feb | git apply -R
pavel at amd:/data/l/linux-n900$ git show
604fdfa45886f04ad6070c1b8266c7f4154bc497 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
d2b8d695c61c4d2864eee900bebc2ced4f425645 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
fa1572d956ee072e965da01d2c46f10d2b67d017 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
62aa292b3eae920a80c2fd0ed0601a70328627f6 | git apply -R
pavel at amd:/data/l/linux-n900$
...seems to be broken already. I guess its time to
bisect... hmm. Tried bisecting, but soundcard does not work
there. Will do it manually...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH v2 2/2] ARM: exynos_defconfig: Remove old non-working MIPI driver
From: Krzysztof Kozlowski @ 2016-09-16 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b3688bb-8dcb-24d4-8112-a0cc56573e48@ti.com>
On 09/07/2016 10:14 AM, Tomi Valkeinen wrote:
> On 01/09/16 14:49, Krzysztof Kozlowski wrote:
>> The Exynos MIPI driver does not work anymore (it is board file only) so
>> it is removed. Remove also config option.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>
>> ---
>>
>> Changes since v1:
>> 1. New patch.
>> ---
>> arch/arm/configs/exynos_defconfig | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
>> index 4e484f406419..fea8edef1534 100644
>> --- a/arch/arm/configs/exynos_defconfig
>> +++ b/arch/arm/configs/exynos_defconfig
>> @@ -168,7 +168,6 @@ CONFIG_DRM_PANEL_SAMSUNG_LD9040=y
>> CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=y
>> CONFIG_DRM_NXP_PTN3460=y
>> CONFIG_DRM_PARADE_PS8622=y
>> -CONFIG_EXYNOS_VIDEO=y
>> CONFIG_EXYNOS_MIPI_DSI=y
>
> EXYNOS_MIPI_DSI too?
Yes, this one too. I'll send a v2. I think these patches can safely go
through different trees (removal of driver through your tree and
defconfig through arm-soc).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Kishon Vijay Abraham I @ 2016-09-16 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCCDDwydB+RP0CZKoAW5Suxotn224ZFVWvt2OGW3gNJR1g@mail.gmail.com>
Hi,
On Friday 09 September 2016 09:44 PM, Martin Blumenstingl wrote:
> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> However, the problem with all of the solutions proposed (runtime PM ones
>> included) is that we're forcing a board-specific design issue (2 devices
>> sharing a reset line) into a driver that should not have any
>> board-specific assumptions in it.
>>
>> For example, if this driver is used on another platform where different
>> PHYs have different reset lines, then one of them (the unlucky one who
>> is not probed first) will never get reset. So any form of per-device
>> ref-counting is not a portable solution.
> maybe we should also consider Ben's solution: he played with the USB
> PHY on his Meson8b board. His approach was to have only one USB PHY
> driver instance which exposes two PHYs.
> The downside of this: the driver would have to know the offset of the
> PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle
> the reset using runtime PM without any hacks.
I think the offset information can come from the devicetree too. The phy can be
modeled something like below.
usb-phys at c0000000 {
compatible = "amlogic,meson-gxbb-usb2-phy";
reg = <0x0 0xc0000000 0x0 0x40>;
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc0000000 0x0 0x40>;
resets = <&reset 34>;
usb0_phy: usb_phy at 0 {
#phy-cells = <0>;
reg = <0x0 0x0 0x0 0x20>;
clocks = <&clkc CLKID_USB &clkc CLKID_USB0>;
clock-names = "usb_general", "usb";
status = "disabled";
};
usb1_phy: usb_phy at 20 {
#phy-cells = <0>;
reg = <0x0 0x20 0x0 0x20>;
clocks = <&clkc CLKID_USB &clkc CLKID_USB1>;
clock-names = "usb_general", "usb";
status = "disabled";
};
};
This way the driver will be probed only once (the reset can be done during
probe). The phy driver should scan the dt node and for every sub-node it
invokes phy_create?
Thanks
Kishon
^ permalink raw reply
* [PATCH] arm64: tegra: Add missing Smaug revision
From: Alexandre Courbot @ 2016-09-16 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL1qeaF+Zck_p_1d-cNMvoJ8oMn7c65wL21E6LjGVVMA3BY2yA@mail.gmail.com>
Not seeing this patch in -next, can someone pick it?
On Fri, Jul 1, 2016 at 1:15 AM, Andrew Bresticker <abrestic@chromium.org> wrote:
> On Wed, Jun 29, 2016 at 1:52 AM, Alexandre Courbot <acourbot@nvidia.com> wrote:
>> The "google,smaug-rev2" string is missing from the compatible list of
>> Smaug's DT. The differences of rev2 are not relevant at our current
>> level of support and it boots just fine, so add it.
>>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>
> Acked-by: Andrew Bresticker <abrestic@chromium.org>
>
>> ---
>> arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
>> index 431266a48e9c..82a96bd27bc8 100644
>> --- a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
>> +++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
>> @@ -11,7 +11,8 @@
>> compatible = "google,smaug-rev8", "google,smaug-rev7",
>> "google,smaug-rev6", "google,smaug-rev5",
>> "google,smaug-rev4", "google,smaug-rev3",
>> - "google,smaug-rev1", "google,smaug", "nvidia,tegra210";
>> + "google,smaug-rev2", "google,smaug-rev1",
>> + "google,smaug", "nvidia,tegra210";
>>
>> aliases {
>> serial0 = &uarta;
>> --
>> 2.9.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend
From: Daniel Lezcano @ 2016-09-16 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DBA81F.2060404@arm.com>
On 16/09/2016 10:06, Marc Zyngier wrote:
> Hi Brian,
>
> On 16/09/16 06:49, Brian Norris wrote:
>> Since commit 4fbcdc813fb9 ("clocksource: arm_arch_timer: Use clocksource
>> for suspend timekeeping"), this driver assumes that the ARM architected
>> timer keeps running in suspend. This is not the case for some ARM SoCs,
>> depending on the HW state used for system suspend. Let's not assume that
>> all SoCs support this, and instead only support this if the device tree
>> explicitly tells us it's "always on". In all other cases, just fall back
>> to the RTC. This should be relatively harmless.
>
> I'm afraid you're confusing two things:
> - the counter, which *must* carry on counting no matter what, as
> (quoting the ARM ARM) "The system counter must be implemented in an
> always-on power domain"
> - the timer, which is allowed to be powered off, and can be tagged with
> the "always-on" property to indicate that it is guaranteed to stay up
> (which in practice only exists in virtual machines and never on real HW).
>
> If your counter does stop counting when suspended, then this is starting
> to either feel like a HW bug, or someone is killing the clock that feeds
> this counter when entering suspend.
>
> If this is the former, then we need a separate quirk to indicate the
> non-standard behaviour. If it is the latter, don't do it! ;-)
+1
-- Daniel
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH BUGFIX] mtd: nand: mxc: fix obiwan error in mxc_nand_v[12]_ooblayout_free() functions
From: Lothar Waßmann @ 2016-09-16 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915180605.4aed48d3@bbrezillon>
Hi,
On Thu, 15 Sep 2016 18:06:05 +0200 Boris Brezillon wrote:
> Hi Lothar,
>
> On Fri, 9 Sep 2016 16:44:11 +0200
> Lothar Wa?mann <LW@KARO-electronics.de> wrote:
>
> > commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
> > introduced a regression accessing the OOB area from the mxc_nand
> > driver due to an Obiwan error in the mxc_nand_v[12]_ooblayout_free()
> > functions. They report a bogus oobregion { 64, 7 } which leads to
> > errors accessing bogus data when reading the oob area.
> >
> > Prior to the commit the mtd-oobtest module could be run without any
> > errors. With the offending commit, this test fails with results like:
> > |Running mtd-oobtest
> > |
> > |=================================================
> > |mtd_oobtest: MTD device: 5
> > |mtd_oobtest: MTD device size 524288, eraseblock size 131072, page size 2048, count of eraseblocks 4, pages per eraseblock 64, OOB size 64
> > |mtd_test: scanning for bad eraseblocks
> > |mtd_test: scanned 4 eraseblocks, 0 are bad
> > |mtd_oobtest: test 1 of 5
> > |mtd_oobtest: writing OOBs of whole device
> > |mtd_oobtest: written up to eraseblock 0
> > |mtd_oobtest: written 4 eraseblocks
> > |mtd_oobtest: verifying all eraseblocks
> > |mtd_oobtest: error @addr[0x0:0x19] 0x9a -> 0x78 diff 0xe2
> > |mtd_oobtest: error @addr[0x0:0x1a] 0xcc -> 0x0 diff 0xcc
> > |mtd_oobtest: error @addr[0x0:0x1b] 0xe0 -> 0x85 diff 0x65
> > |mtd_oobtest: error @addr[0x0:0x1c] 0x60 -> 0x62 diff 0x2
> > |mtd_oobtest: error @addr[0x0:0x1d] 0x69 -> 0x45 diff 0x2c
> > |mtd_oobtest: error @addr[0x0:0x1e] 0xcd -> 0xa0 diff 0x6d
> > |mtd_oobtest: error @addr[0x0:0x1f] 0xf2 -> 0x60 diff 0x92
> > |mtd_oobtest: error: verify failed at 0x0
> > [...]
> >
> > Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
> > ---
> > drivers/mtd/nand/mxc_nand.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> > index 5173fad..fdee907 100644
> > --- a/drivers/mtd/nand/mxc_nand.c
> > +++ b/drivers/mtd/nand/mxc_nand.c
> > @@ -893,7 +893,7 @@ static int mxc_v1_ooblayout_free(struct mtd_info *mtd, int section,
> > {
> > struct nand_chip *nand_chip = mtd_to_nand(mtd);
> >
> > - if (section > nand_chip->ecc.steps)
> > + if (section >= nand_chip->ecc.steps)
> > return -ERANGE;
>
> Hm, looking at the commit you're pointing to, it seems that this test
> is correct (we have X + 1 free sections, where X is the number of ECC
> steps).
>
You are right. I didn't verify the v1 case (for which I have no HW here
any more).
I'll send a corrected patch.
Lothar Wa?mann
^ permalink raw reply
* [PATCH] MAINTAINERS: update list of Oxnas maintainers
From: Neil Armstrong @ 2016-09-16 8:09 UTC (permalink / raw)
To: linux-arm-kernel
Add a new list address in the MAINTAINERS file for the Oxnas platform.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 71aa5da..5470e42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1442,6 +1442,7 @@ F: arch/arm/mach-orion5x/ts78xx-*
ARM/OXNAS platform support
M: Neil Armstrong <narmstrong@baylibre.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+L: linux-oxnas at lists.tuxfamily.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-oxnas/
F: arch/arm/boot/dts/oxnas*
--
2.7.0
^ permalink raw reply related
* [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend
From: Marc Zyngier @ 2016-09-16 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916054917.16930-1-briannorris@chromium.org>
Hi Brian,
On 16/09/16 06:49, Brian Norris wrote:
> Since commit 4fbcdc813fb9 ("clocksource: arm_arch_timer: Use clocksource
> for suspend timekeeping"), this driver assumes that the ARM architected
> timer keeps running in suspend. This is not the case for some ARM SoCs,
> depending on the HW state used for system suspend. Let's not assume that
> all SoCs support this, and instead only support this if the device tree
> explicitly tells us it's "always on". In all other cases, just fall back
> to the RTC. This should be relatively harmless.
I'm afraid you're confusing two things:
- the counter, which *must* carry on counting no matter what, as
(quoting the ARM ARM) "The system counter must be implemented in an
always-on power domain"
- the timer, which is allowed to be powered off, and can be tagged with
the "always-on" property to indicate that it is guaranteed to stay up
(which in practice only exists in virtual machines and never on real HW).
If your counter does stop counting when suspended, then this is starting
to either feel like a HW bug, or someone is killing the clock that feeds
this counter when entering suspend.
If this is the former, then we need a separate quirk to indicate the
non-standard behaviour. If it is the latter, don't do it! ;-)
>
> It seems fair to key the system-suspend behavior off the same property
> used for C3STOP, since if the timer doesn't keep context for CPU sleep,
> it likely doesn't for system sleep either.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> drivers/clocksource/arm_arch_timer.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 57700541f951..e28677a34f02 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -490,7 +490,7 @@ static struct clocksource clocksource_counter = {
> .rating = 400,
> .read = arch_counter_read,
> .mask = CLOCKSOURCE_MASK(56),
> - .flags = CLOCK_SOURCE_IS_CONTINUOUS | CLOCK_SOURCE_SUSPEND_NONSTOP,
> + .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> };
>
> static struct cyclecounter cyclecounter = {
> @@ -526,6 +526,8 @@ static void __init arch_counter_register(unsigned type)
> clocksource_counter.name = "arch_mem_counter";
> }
>
> + if (!arch_timer_c3stop)
> + clocksource_counter.flags |= CLOCK_SOURCE_SUSPEND_NONSTOP;
> start_count = arch_timer_read_counter();
> clocksource_register_hz(&clocksource_counter, arch_timer_rate);
> cyclecounter.mult = clocksource_counter.mult;
>
Given the above, I don't think this patch is acceptable.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH v2 2/5] clk: hi3620: Make 3620 explicit, remove wildcard
From: Arnd Bergmann @ 2016-09-16 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915210505.21878-3-netz.kernel@gmail.com>
On Thursday, September 15, 2016 4:05:02 PM CEST Marty Plummer wrote:
> diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
> index e169ec7..2edf3b5 100644
> --- a/drivers/clk/hisilicon/Makefile
> +++ b/drivers/clk/hisilicon/Makefile
> @@ -4,7 +4,7 @@
>
> obj-y += clk.o clkgate-separated.o clkdivider-hi6220.o
>
> -obj-$(CONFIG_ARCH_HI3xxx) += clk-hi3620.o
> +obj-$(CONFIG_ARCH_HI3620) += clk-hi3620.o
> obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o
> obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
> obj-$(CONFIG_COMMON_CLK_HI3519) += clk-hi3519.o
I'd suggest instead adding a new Kconfig symbol for the clock driver
the same way we handle hi3519.
Arnd
^ permalink raw reply
* [RFC PATCH v2 3/5] dmaengine: hi3620: Make hi3620 explicit, remove wildcard
From: Arnd Bergmann @ 2016-09-16 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915210505.21878-4-netz.kernel@gmail.com>
On Thursday, September 15, 2016 4:05:03 PM CEST Marty Plummer wrote:
> Signed-off-by: Marty Plummer <netz.kernel@gmail.com>
> ---
> drivers/dma/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 739f797..74bab9d0 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -279,7 +279,7 @@ config INTEL_MIC_X100_DMA
>
> config K3_DMA
> tristate "Hisilicon K3 DMA support"
> - depends on ARCH_HI3xxx
> + depends on ARCH_HI3620
> select DMA_ENGINE
> select DMA_VIRTUAL_CHANNELS
> help
>
This can not be applied until the first patch is merged.
If we leave a ARCH_HI3xxx Kconfig symbol in place indefinitely,
I think it's ok to just leave it the way it is right now
and drop the patch: there are many other drivers for hardware
you don't have and we just leave them disabled in the .config,
so we can do the same here.
Arnd
^ permalink raw reply
* [RFC PATCH v2 5/5] ARM: hisi: add devicetree for hi3520
From: Arnd Bergmann @ 2016-09-16 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915210505.21878-6-netz.kernel@gmail.com>
On Thursday, September 15, 2016 4:05:05 PM CEST Marty Plummer wrote:
> diff --git a/arch/arm/boot/dts/hi3520-1176-dm77a.dts b/arch/arm/boot/dts/hi3520-1176-dm77a.dts
> new file mode 100644
> index 0000000..c87a18e
> --- /dev/null
> +++ b/arch/arm/boot/dts/hi3520-1176-dm77a.dts
> @@ -0,0 +1,62 @@
> +/*
> + * Copyright (C) 2016 Marty Plummer <netz.kernel@gmail.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +/dts-v1/;
> +#include "hi3520-1176.dtsi"
> +
> +/ {
> + model = "Nightowl zeus-dvr";
> + compatible = "hisilicon,hi3520-1176";
Please add a board specific compatible string in front of the string
for the soc.
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + serial3 = &uart3;
> + };
Do you actually have access to all four serial ports on this board?
If not, just add aliases for the ones you see.
> + /* chosen { */
> + /* bootargs = "mem=72M console=ttyAMA0,115200 root=/dev/ram"; */
> + /* stdout-path = "serial0:115200n8"; */
> + /* }; */
I'd leave the stdout-path property in here, but not the bootargs.
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,arm1176jzf-s";
> + reg = <0>;
> + };
> + };
I guess in the long run we will want to support both the ARM926 and
the ARM1176, so maybe split the .dtsi file into two: one for whatever
is common to both cores, and one for the ARM1176 CPU and anything
exlusively used by that.
> +
> + amba {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + ranges;
> +
> + uart0: uart at 20090000 {
The name should be serial at 20090000
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x20090000 0x1000>;
> + clocks = <&uartclk &clk_3m>;
> + clock-names = "uartclk", "apb_pclk";
> + interrupts-extended = <&vic0 12 4>;
> + status = "disable";
> + };
status="disabled" (with 'd')
> +
> + uart1: uart at 200a0000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x200a0000 0x1000>;
> + clocks = <&uartclk &clk_3m>;
> + clock-names = "uartclk", "apb_pclk";
> + interrupts-extended = <&vic0 12 4>;
> + };
> +
> + uart2: uart at 200b0000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x200b0000 0x1000>;
> + clocks = <&uartclk &clk_3m>;
> + clock-names = "uartclk", "apb_pclk";
> + interrupts-extended = <&vic0 13 4>;
> + };
> +
> + uart3: uart at 200c0000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x200c0000 0x1000>;
> + clocks = <&uartclk &clk_3m>;
> + clock-names = "uartclk", "apb_pclk";
> + interrupts-extended = <&vic0 13 4>;
> + };
Why are these not disabled?
> + gpio0: gpio at 20150000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x20150000 0x1000>;
> + interrupts-extended = <&vic1 6 4>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + clocks = <&uartclk &clk_3m>;
> + clock-names = "apb_pclk";
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + status = "disabled";
> + };
This one should probably not be disabled in turn.
> + dual_timer0: dual_timer at 20000000 {
timer at 20000000
> + spi_bus0: spi at 200e0000 {
> + compatible = "arm,pl022", "arm,primecell";
> + reg = <0x200e0000 0x1000>;
> + interrupts-extended = <&vic0 11 4>;
> + num-cs = <1>;
> + };
> + };
There should be a #address-cells, also you probably want to
disable this if there are no child devices.
> + sysctrl: system-controller at 20050000 {
> + compatible = "hisilicon,hi3520-sysctrl", "syscon";
> + reg = <0x20050000 0x1000>;
> + };
The new compatible string needs to be listed in the sysctrl binding
document.
> +
> + reboot {
> + compatible = "syscon-reboot";
> + regmap = <&sysctrl>;
> + offset = <0x4>;
> + mask = <0xdeadbeef>;
> + };
> +
> + /* gmac0: ethernet at 10090000 { */
> + /* compatible = "hisilicon,hix5hd2-gmac"; */
> + /* reg = <0x10090000 0x1000>,<0x20050000 0x1000>; */
> + /* interrupts-extended = <&vic0 14 4>; */
> + /* clocks = <&clk_3m>; */
> + /* status = "disabled"; */
> + /* }; */
> +
> + usb0: ehci at 100b0000 {
usb at 100b0000
Arnd
^ permalink raw reply
* [RFC PATCH v2 4/5] ARM: hisi: enable devicetree support for hi3520
From: Arnd Bergmann @ 2016-09-16 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915210505.21878-5-netz.kernel@gmail.com>
On Thursday, September 15, 2016 4:05:04 PM CEST Marty Plummer wrote:
> @@ -24,17 +31,19 @@ config ARCH_HI3620
> Support for Hisilicon Hi36xx SoC family
>
> config ARCH_HIP01
> - bool "Hisilicon HIP01 family"
> - depends on ARCH_MULTI_V7
> - select HAVE_ARM_SCU if SMP
> - select HAVE_ARM_TWD if SMP
> - select ARM_GLOBAL_TIMER
> - help
> - Support for Hisilicon HIP01 SoC family
> + bool "Hisilicon HIP01 family"
> + depends on ARCH_MULTI_V7
> + select ARM_GIC
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if SMP
> + select ARM_GLOBAL_TIMER
> + help
> + Support for Hisilicon HIP01 SoC family
>
This change doesn't belong in here.
> @@ -28,6 +30,16 @@
> * spaces wasted since ioremap() may be called multi times for the same
> * IO space.
> */
> +static struct map_desc hi3520_1176_io_desc[] __initdata = {
> + {
> + /* sysctrl */
> + .virtual = HI3520_1176_SYSCTRL_VIRT_BASE,
> + .pfn = __phys_to_pfn(HI3520_1176_SYSCTRL_PHYS_BASE),
> + .length = 0x10000,
> + .type = MT_DEVICE,
> + },
> +};
> +
> static struct map_desc hi3620_io_desc[] __initdata = {
> {
> /* sysctrl */
What do you need this for? I think it would be better to map the
device manually from whichever code uses itby looking it up
in the DT.
Arnd
^ permalink raw reply
* [PATCH v3 01/17] pinctrl: dt-bindings: samsung: Add header with values used for configuration
From: Krzysztof Kozlowski @ 2016-09-16 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb9gq0Zez=_NW8XB6YKiJteC3GB12e-Wi9my52b4Q-C7A@mail.gmail.com>
On 09/07/2016 11:18 PM, Linus Walleij wrote:
> On Sun, Sep 4, 2016 at 1:04 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
>> From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>
>> Hard-coded pinctrl configuration values are scattered through DTS files.
>> The numbers are difficult to decode by human, especially without the
>> datasheet. Additionally the drive strength differs between S3C64xx,
>> S5PV210 and Exynos SoC families increasing the confusion.
>>
>> The header will help making this more readable and maintainable.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Take this with the rest of the changes into ARM SoC.
Thanks!
Applied entire patchset.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 0/5] Cavium ThunderX uncore PMU support
From: Will Deacon @ 2016-09-16 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160704101132.GC1639@arm.com>
Hi Jan,
On Mon, Jul 04, 2016 at 11:11:32AM +0100, Will Deacon wrote:
> On Tue, Jun 28, 2016 at 04:04:59PM +0200, Jan Glauber wrote:
> > On Tue, Jun 28, 2016 at 11:24:20AM +0100, Will Deacon wrote:
> > > On Wed, Mar 09, 2016 at 05:21:02PM +0100, Jan Glauber wrote:
> > > > This patch series provides access to various counters on the ThunderX SOC.
> > > >
> > > > For details of the uncore implementation see patch #1.
> > > >
> > > > Patches #2-5 add the various ThunderX specific PMUs.
> > > >
> > > > As suggested I've put the files under drivers/perf/uncore. I would
> > > > prefer this location over drivers/bus because not all of the uncore
> > > > drivers are bus related.
> > >
> > > What's the status of these patches? Were you planning to send a new
> > > version?
> >
> > I was half-way through with addressing Mark's review comments when
> > got side-tracked.
> >
> > The principle question these patches raised remains open though in my
> > opinion, how to determine the socket a device belongs to.
> >
> > There is no first-class interface to ask a device or the firmware
> > which socket the device lives on.
> >
> > The options I see are:
> > A) Using NUMA node information, depends on CONFIG_NUMA
> > B) Decoding the socket bits of the PCI BAR address
> > C) Using PCI topology information
> >
> > A is what I tried, but I agree that depending on CONFIG_NUMA is not a good
> > solution. B would be easy but looks not very future-proof. So option C
> > is what is left...
>
> Sorry to go full circle on this, but "depends on NUMA" sounds better
> than deriving NUMA topology from PCI to me. The only worry I have is if
> the NUMA information ends up being insufficient in the long-term, and we
> end up with a mixture of the three options above in order to figure out
> the PMU topology.
>
> As long as you're happy that the PMU:NUMA topology remains 1:1, then I
> have no objections. The moment you need extra hacks on the side, we should
> probably drop the NUMA dependency altogether and figure it out some other
> way.
Any news on this series, or did I miss a v3? I was hoping to have this in
for 4.9, but it seems to have stalled :(
Will
^ permalink raw reply
* [GIT PULL] STi DT update for v4.9, round 3
From: Patrice Chotard @ 2016-09-16 7:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, Olof
PLease consider this next batch for v4.9, dedicated for clock improvements
The following changes since commit 443fd7c92f5a000796b02683157d17b2575450e1:
ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card (2016-09-14 13:37:29 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git tags/sti-dt-for-v4.9-3
for you to fetch changes up to 3a74152ce62e7ec1b8a5604b10e40d2a66d8f43b:
ARM: dts: STiH410: clock configuration to address 720p and 1080p (2016-09-16 09:42:13 +0200)
----------------------------------------------------------------
Clock improvement for video playback
This serie allows to increase video resolutions and make audio
adjustment during a video playback for STiH407 family socs.
----------------------------------------------------------------
Gabriel Fernandez (9):
ARM: dts: STiH4xx: Simplify clock binding of STiH4xx platforms
ARM: dts: STiH407: Enable clock propagation for audio clocks
ARM: dts: STiH410: Enable clock propagation for audio clocks
ARM: dts: STiH418: Enable clock propagation for audio clocks
ARM: dts: STiH407: Enable synchronous clock mode for video clocks
ARM: dts: STiH410: Enable synchronous clock mode for video clocks
ARM: dts: STiH418: Enable synchronous clock mode for video clocks
ARM: dts: STi: STiH407: clock configuration to address 720p and 1080p
ARM: dts: STiH410: clock configuration to address 720p and 1080p
arch/arm/boot/dts/stih407-clock.dtsi | 22 +++++++++++-----------
arch/arm/boot/dts/stih407.dtsi | 16 +++++++++++++---
arch/arm/boot/dts/stih410-clock.dtsi | 20 ++++++++++----------
arch/arm/boot/dts/stih410.dtsi | 16 +++++++++++++---
arch/arm/boot/dts/stih418-clock.dtsi | 20 ++++++++++----------
5 files changed, 57 insertions(+), 37 deletions(-)
^ permalink raw reply
* [RFC PATCH v2 1/5] ARM: hisi: Make 3620 explicit, remove wildcards
From: Arnd Bergmann @ 2016-09-16 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915210505.21878-2-netz.kernel@gmail.com>
On Thursday, September 15, 2016 4:05:01 PM CEST Marty Plummer wrote:
> --- a/arch/arm/mach-hisi/Kconfig
> +++ b/arch/arm/mach-hisi/Kconfig
> @@ -12,8 +12,8 @@ if ARCH_HISI
>
> menu "Hisilicon platform type"
>
> -config ARCH_HI3xxx
> - bool "Hisilicon Hi36xx family"
> +config ARCH_HI3620
> + bool "Hisilicon Hi3620 family"
> depends on ARCH_MULTI_V7
> select CACHE_L2X0
> select HAVE_ARM_SCU if SMP
>
This breaks bisection by removing the ARCH_HI3xxx symbol that
the other drivers still rely on until the entire series is
applied.
I'd suggest introducing a hidden ARCH_HI3xxx symbol like
config ARCH_HI3xxx
bool
config ARCH_HI3620
bool "Hisilicon Hi3620 family"
select ARCH_HI3xxx
...
Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox