* [PATCH 2/3] memremap: add MEMREMAP_EXEC and MEMREMAP_EXEC_NOCACHE flags
From: Dave Gerlach @ 2016-10-27 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027185612.22362-1-d-gerlach@ti.com>
Add flags to memremap() for MEMREMAP_EXEC and MEMREMAP_EXEC_NOCACHE
mappings. Mappings provided by these flags will both allow execution,
with MEMREMAP_EXEC_NOCACHE also requiring the memory to be mapped
non-cached. These mappings are useful for architectures that must map
on-chip memory such as SRAM and then copy and execute code from it, such
as code used to reconfigure system memory controllers or the low-level PM
code on ARM platforms.
Also add stubs for both underlying arch_memremap_exec/nocache calls that
return NULL so that if either is attempted from a platform cannot map
memory in such a way will fail.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
include/linux/io.h | 2 ++
kernel/memremap.c | 34 +++++++++++++++++++++++++++++++++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/include/linux/io.h b/include/linux/io.h
index e2c8419278c1..6668b6b9123b 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -136,6 +136,8 @@ enum {
MEMREMAP_WB = 1 << 0,
MEMREMAP_WT = 1 << 1,
MEMREMAP_WC = 1 << 2,
+ MEMREMAP_EXEC = 1 << 3,
+ MEMREMAP_EXEC_NOCACHE = 1 << 4,
};
void *memremap(resource_size_t offset, size_t size, unsigned long flags);
diff --git a/kernel/memremap.c b/kernel/memremap.c
index b501e390bb34..47cefc64057d 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -34,6 +34,21 @@ static void *arch_memremap_wb(resource_size_t offset, unsigned long size)
}
#endif
+#ifndef arch_memremap_exec
+static void *arch_memremap_exec(resource_size_t offset, unsigned long size)
+{
+ return NULL;
+}
+#endif
+
+#ifndef arch_memremap_exec_nocache
+static void *arch_memremap_exec_nocache(resource_size_t offset,
+ unsigned long size)
+{
+ return NULL;
+}
+#endif
+
static void *try_ram_remap(resource_size_t offset, size_t size)
{
unsigned long pfn = PHYS_PFN(offset);
@@ -48,7 +63,8 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
* memremap() - remap an iomem_resource as cacheable memory
* @offset: iomem resource start address
* @size: size of remap
- * @flags: any of MEMREMAP_WB, MEMREMAP_WT and MEMREMAP_WC
+ * @flags: any of MEMREMAP_WB, MEMREMAP_WT, MEMREMAP_WC, MEMREMAP_EXEC,
+ * and MEMREMAP_EXEC_NOCACHE
*
* memremap() is "ioremap" for cases where it is known that the resource
* being mapped does not have i/o side effects and the __iomem
@@ -70,6 +86,16 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
* MEMREMAP_WC - establish a writecombine mapping, whereby writes may
* be coalesced together (e.g. in the CPU's write buffers), but is otherwise
* uncached. Attempts to map System RAM with this mapping type will fail.
+ *
+ * MEMREMAP_EXEC - map memory as cached, as MEMREMAP_WB does, but also
+ * executable to allow for executing code from something like an on-chip
+ * memory. If support for executable mapping is not present on platform
+ * then the mapping will fail.
+ *
+ * MEMREMAP_EXEC_NOCACHE - map memory as non-cached and executable to allow
+ * for executing code from something like an on-chip memory. If support for
+ * executable, non-cached mapping is not present on platform then the
+ * mapping will fail.
*/
void *memremap(resource_size_t offset, size_t size, unsigned long flags)
{
@@ -118,6 +144,12 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
if (!addr && (flags & MEMREMAP_WC))
addr = ioremap_wc(offset, size);
+ if (!addr && (flags & MEMREMAP_EXEC))
+ addr = arch_memremap_exec(offset, size);
+
+ if (!addr && (flags & MEMREMAP_EXEC_NOCACHE))
+ addr = arch_memremap_exec_nocache(offset, size);
+
return addr;
}
EXPORT_SYMBOL(memremap);
--
2.9.3
^ permalink raw reply related
* [PATCH 3/3] misc: SRAM: Add option to map SRAM to allow code execution
From: Dave Gerlach @ 2016-10-27 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027185612.22362-1-d-gerlach@ti.com>
Allow option for mapping SRAM as executable. DT node can specify
"memory-exec" and "memory-exec-nocache" to also map it as non-cached.
This is useful for platforms using the sram driver that need to run
PM code from sram like several ARM platforms.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
Documentation/devicetree/bindings/sram/sram.txt | 2 ++
drivers/misc/sram.c | 7 +++++++
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/sram/sram.txt b/Documentation/devicetree/bindings/sram/sram.txt
index add48f09015e..8eac557204e5 100644
--- a/Documentation/devicetree/bindings/sram/sram.txt
+++ b/Documentation/devicetree/bindings/sram/sram.txt
@@ -29,6 +29,8 @@ Optional properties in the sram node:
- no-memory-wc : the flag indicating, that SRAM memory region has not to
be remapped as write combining. WC is used by default.
+- memory-exec : map range to allow code execution
+- memory-exec-nocache : map range to allow code execution and also non-cached
Required properties in the area nodes:
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index f84b53d6ce50..a9ba1be115bb 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -362,6 +362,13 @@ static int sram_probe(struct platform_device *pdev)
if (of_property_read_bool(pdev->dev.of_node, "no-memory-wc"))
sram->virt_base = devm_ioremap(sram->dev, res->start, size);
+ else if (of_property_read_bool(pdev->dev.of_node, "memory-exec"))
+ sram->virt_base = devm_memremap(sram->dev, res->start, size,
+ MEMREMAP_EXEC);
+ else if (of_property_read_bool(pdev->dev.of_node,
+ "memory-exec-nocache"))
+ sram->virt_base = devm_memremap(sram->dev, res->start, size,
+ MEMREMAP_EXEC_NOCACHE);
else
sram->virt_base = devm_ioremap_wc(sram->dev, res->start, size);
if (!sram->virt_base)
--
2.9.3
^ permalink raw reply related
* Add Allwinner Q8 tablets hardware manager
From: Pierre-Hugues Husson @ 2016-10-27 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <D75CB7DE-4165-4D2F-B40B-D2B6875C0172@konsulko.com>
2016-10-27 19:11 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@konsulko.com>:
>
> Hi Pierre,
>
> > On Oct 27, 2016, at 19:59 , Pierre-Hugues Husson <phh@phh.me> wrote:
> >
> > 2016-10-27 17:52 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@konsulko.com>:
> >> Yes there is no EEPROM but you might be able to map probing results to
> >> a fake ?model? number.
> >>
> >> Let me expand a bit:
> >>
> >> Assume that you have a number of probing steps, for example A, B, C each
> >> returning true or false, and C being executed only when B is ?true? you
> >> could do this to generate a bit field that identifies it.
> >>
> >> For example let?s assume that model FOO?s probing steps are
> >>
> >> A false, B true, C false -> 010
> >>
> >> Model?s BAR
> >>
> >> A true, B false, C don?t care -> 10x
> >>
> >> Mapping these to models could be
> >>
> >> Model FOO, (010 & 111) == 010 (all three probing steps must match)
> >>
> >> Model BAR, (10x & 110) = 100 (the first two probing steps must match)
> >
> > This method looks too complex on multiple grounds.
> > Assuming your method, I'm not too sure how this would actually be
> > described in a DTS.
> > Such probing steps should include reading/matching IDs in an EEPROM/on
> > an ADC, but it should also include the result of a driver's probe.
> > Also, drivers should have a way to report an ID/OTP instead of just a
> > boolean.
> >
>
> Err, I don?t think you got the point.
>
> The probing steps are done by a board specific probe driver.
> This driver performs the probing steps (which is exactly what Hans?s
> method now does) but instead of applying changes to the device tree
> programmatically generates a model string.
>
> This model string can be used by a general purpose overlay manager to apply
> the overlay(s) for the specific board. The plural part is important - read
> below.
Ok, I agree I didn't get the point, and I'm not sure I do now.
If I understand correctly, the difference between your method and
Hans', is that instead of manipulating directly OF properties based on
heuristics, there will be a heuristic to determine model revision, and
THEN apply overlays based on determined model revision.
If this is the correct interpretation, this means that for boards with
two possible accelerometers, a new driver is required, while something
as simple as i2c-probe-stop-at-first-match wouldn't require a new
driver.
> > As you mentioned, it is a way to distinguish models, not just a set of
> > parameters.
> > Does this mean that this DT would lead to loading various DT based on
> > the matching model, which would look like a FIT?
> > Also there is a modularity problem there. If I have phones with either
> > screen A or screen B, and with either accelerometer A or accelerometer
> > B, I would have to implement all four combinations.
> >
>
> The model lookup need not result in a simple overlay to apply.
>
> So for your case it would be:
>
> model corp,0 -> overlay screen A + overlay accel A
> model corp,1 -> overlay screen A + overlay accel B
> model corp,2 -> overlay screen B + overlay accel A
> model corp,3 -> overlay screen B + overlay accel B
>
> You don?t need the combinatorial number of overlays.
My worry initially was that all 4 "model corp" are needed, while with
using a simple approach like i2c-probe-stop-at-first-match, this
wouldn't be needed.
But now that I'm thinking of it again, for such a case to happen, this
would require to have OEMs picking random components for tablets of
one production batch. This wouldn't make any sense.
So I agree a model-based method should cover sufficient cases to be worthwhile.
I think it covers every device I've met.
Regards,
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Pantelis Antoniou @ 2016-10-27 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ-oXjS_=k4qE25t2b9eNnuqvVHf-1g7CZr81pPJx==aftF4xw@mail.gmail.com>
Hi Pierre,
> On Oct 27, 2016, at 22:04 , Pierre-Hugues Husson <phh@phh.me> wrote:
>
> 2016-10-27 19:11 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@konsulko.com>:
>>
>> Hi Pierre,
>>
>>> On Oct 27, 2016, at 19:59 , Pierre-Hugues Husson <phh@phh.me> wrote:
>>>
>>> 2016-10-27 17:52 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@konsulko.com>:
>>>> Yes there is no EEPROM but you might be able to map probing results to
>>>> a fake ?model? number.
>>>>
>>>> Let me expand a bit:
>>>>
>>>> Assume that you have a number of probing steps, for example A, B, C each
>>>> returning true or false, and C being executed only when B is ?true? you
>>>> could do this to generate a bit field that identifies it.
>>>>
>>>> For example let?s assume that model FOO?s probing steps are
>>>>
>>>> A false, B true, C false -> 010
>>>>
>>>> Model?s BAR
>>>>
>>>> A true, B false, C don?t care -> 10x
>>>>
>>>> Mapping these to models could be
>>>>
>>>> Model FOO, (010 & 111) == 010 (all three probing steps must match)
>>>>
>>>> Model BAR, (10x & 110) = 100 (the first two probing steps must match)
>>>
>>> This method looks too complex on multiple grounds.
>>> Assuming your method, I'm not too sure how this would actually be
>>> described in a DTS.
>>> Such probing steps should include reading/matching IDs in an EEPROM/on
>>> an ADC, but it should also include the result of a driver's probe.
>>> Also, drivers should have a way to report an ID/OTP instead of just a
>>> boolean.
>>>
>>
>> Err, I don?t think you got the point.
>>
>> The probing steps are done by a board specific probe driver.
>> This driver performs the probing steps (which is exactly what Hans?s
>> method now does) but instead of applying changes to the device tree
>> programmatically generates a model string.
>>
>> This model string can be used by a general purpose overlay manager to apply
>> the overlay(s) for the specific board. The plural part is important - read
>> below.
>
> Ok, I agree I didn't get the point, and I'm not sure I do now.
> If I understand correctly, the difference between your method and
> Hans', is that instead of manipulating directly OF properties based on
> heuristics, there will be a heuristic to determine model revision, and
> THEN apply overlays based on determined model revision.
>
> If this is the correct interpretation, this means that for boards with
> two possible accelerometers, a new driver is required, while something
> as simple as i2c-probe-stop-at-first-match wouldn't require a new
> driver.
>
It does require a new driver, but the driver is simple a probing method
driver; it does not require to modify the actual drivers that are going
to be instantiated.
In DT terms for a board specific probe driver:
bpm: board_probe_method {
compatible = ?foocorp,bar-board-probe?;
};
genm: generic_model_manager {
compatible = ?generic-model-manager?;
probe-method = <&bpm>;
/* list of models and overlays to apply in sequence */
models {
foo-model-0 = ?foo,bar,screen-A?, ?foo,bar,accel-A?;
foo-model-1 = ?foo,bar,screen-A?, ?foo,bar,accel-B?;
foo-model-2 = ?foo,bar,screen-B?, ?foo,bar,accel-A?;
foo-model-3 = ?foo,bar,screen-B?, ?foo,bar,accel-B?;
};
};
The manager can call the single exported method which could be as simple
as:
const char *probe_identify();
In fact for things like i2c probe a generic probe method might suffice.
i2c_generic_bpm: generic_i2c_probe_method {
compatible = ?i2c-generic-probe-method?;
models {
model at 0 {
result = ?foo-model-0?;
/* match when read at address 12 returns 5 */
/* and read at address 14 returns 0 */
/* format is command, bus, address, argument */
match = <MATCH_READ &i2c0 12 5>, <MATCH_READ &i2c0 0 14 0>;
? etc ...
};
};
};
>>> As you mentioned, it is a way to distinguish models, not just a set of
>>> parameters.
>>> Does this mean that this DT would lead to loading various DT based on
>>> the matching model, which would look like a FIT?
>>> Also there is a modularity problem there. If I have phones with either
>>> screen A or screen B, and with either accelerometer A or accelerometer
>>> B, I would have to implement all four combinations.
>>>
>>
>> The model lookup need not result in a simple overlay to apply.
>>
>> So for your case it would be:
>>
>> model corp,0 -> overlay screen A + overlay accel A
>> model corp,1 -> overlay screen A + overlay accel B
>> model corp,2 -> overlay screen B + overlay accel A
>> model corp,3 -> overlay screen B + overlay accel B
>>
>> You don?t need the combinatorial number of overlays.
>
> My worry initially was that all 4 "model corp" are needed, while with
> using a simple approach like i2c-probe-stop-at-first-match, this
> wouldn't be needed.
> But now that I'm thinking of it again, for such a case to happen, this
> would require to have OEMs picking random components for tablets of
> one production batch. This wouldn't make any sense.
> So I agree a model-based method should cover sufficient cases to be worthwhile.
> I think it covers every device I've met.
>
Yeah, model number in this case means both model and revision.
If components change you change the internal model number.
> Regards,
Regards
? Pantelis
^ permalink raw reply
* [PATCH 7/9] Input: wm97xx: split out touchscreen registering
From: Robert Jarzmik @ 2016-10-27 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027090233.GF28180@localhost.localdomain>
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> writes:
> On Wed, Oct 26, 2016 at 09:41:45PM +0200, Robert Jarzmik wrote:
>> diff --git a/drivers/input/touchscreen/wm97xx-core.c b/drivers/input/touchscreen/wm97xx-core.c
>> index 83cf11312fd9..50a110e2988b 100644
> <snip>
>> +static void wm97xx_remove_battery(struct wm97xx *wm)
>> +{
>> + platform_device_put(wm->battery_dev);
>> +}
> <snip>
>> @@ -724,10 +757,8 @@ static int wm97xx_remove(struct device *dev)
>> {
>> struct wm97xx *wm = dev_get_drvdata(dev);
>>
>> - platform_device_unregister(wm->battery_dev);
>> - platform_device_unregister(wm->touch_dev);
>> - input_unregister_device(wm->input_dev);
>> - kfree(wm);
>> + wm97xx_remove_battery(wm);
>
> The commit message says this is just shifting code around but the
> platform_device_unregister for the battery_dev seems to have
> turned into a platform_device_put here.
Thanks for spotting that, it's clearly a defect in the patch.
That implies a v2 at least for this one.
Cheers.
--
Robert
^ permalink raw reply
* [PATCHv2 0/4] Add Altera A10SR Status & Control Monitor
From: tthayer at opensource.altera.com @ 2016-10-27 20:00 UTC (permalink / raw)
To: linux-arm-kernel
From: Thor Thayer <tthayer@opensource.altera.com>
This patch series adds the Altera Arria10 DevKit System Resource
chip's Status and Control Monitor to the A10SR Multi-Function
Device. An earlier patch added this to the hwmon class which
wasn't the proper place so this functionality is added to the
misc directory.
Version 2 changes the DT names from -mon to -monitor for better
readability and clarity and changed the previous version from
modular to built-in.
Thor Thayer (4):
dt-bindings: mfd: Add Altera Arria10 SR Monitor
misc: Add Altera Arria10 System Resource Control
mfd: altr-a10sr: Add Arria10 SR Monitor
ARM: socfpga: dts: Add Monitor to A10-SR MFD
.../devicetree/bindings/mfd/altera-a10sr.txt | 9 ++
MAINTAINERS | 1 +
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 4 +
drivers/mfd/altera-a10sr.c | 4 +
drivers/misc/Kconfig | 7 +
drivers/misc/Makefile | 1 +
drivers/misc/altera-a10sr-monitor.c | 176 +++++++++++++++++++++
7 files changed, 202 insertions(+)
create mode 100644 drivers/misc/altera-a10sr-monitor.c
--
1.9.1
^ permalink raw reply
* [PATCHv2 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: tthayer at opensource.altera.com @ 2016-10-27 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477598426-28125-1-git-send-email-tthayer@opensource.altera.com>
From: Thor Thayer <tthayer@opensource.altera.com>
Add the Arria10 DevKit System Resource Chip register and state
monitoring module to the MFD.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
---
Note: This needs to be applied to the bindings document that
was Acked & Applied but didn't reach the for-next branch.
See https://patchwork.ozlabs.org/patch/629397/
---
v2 Change compatible string -mon to -monitor for clarity
---
Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
index ea151f2..c47be28 100644
--- a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
+++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
@@ -18,6 +18,7 @@ The A10SR consists of these sub-devices:
Device Description
------ ----------
a10sr_gpio GPIO Controller
+a10sr_monitor Register and State Monitoring
Arria10 GPIO
Required Properties:
@@ -27,6 +28,10 @@ Required Properties:
the second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
+Arria10 Register and State Monitor
+Required Properties:
+- compatible : Should be "altr,a10sr-monitor"
+
Example:
resource-manager at 0 {
@@ -43,4 +48,8 @@ Example:
gpio-controller;
#gpio-cells = <2>;
};
+
+ a10sr_monitor {
+ compatible = "altr,a10sr-monitor";
+ };
};
--
1.9.1
^ permalink raw reply related
* [PATCHv2 2/4] misc: Add Altera Arria10 System Resource Control
From: tthayer at opensource.altera.com @ 2016-10-27 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477598426-28125-1-git-send-email-tthayer@opensource.altera.com>
From: Thor Thayer <tthayer@opensource.altera.com>
This patch adds the Altera Arria10 control & monitoring
functions to the Arria10 System Resource chip.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
---
v2 Change compatible string and filename from -mon to -monitor
Change CONFIG from module to builtin.
Make wm_rst register writeable.
---
MAINTAINERS | 1 +
drivers/misc/Kconfig | 7 ++
drivers/misc/Makefile | 1 +
drivers/misc/altera-a10sr-monitor.c | 176 ++++++++++++++++++++++++++++++++++++
4 files changed, 185 insertions(+)
create mode 100644 drivers/misc/altera-a10sr-monitor.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 813ea85..1c5b0be 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -631,6 +631,7 @@ M: Thor Thayer <tthayer@opensource.altera.com>
S: Maintained
F: drivers/gpio/gpio-altera-a10sr.c
F: drivers/mfd/altera-a10sr.c
+F: drivers/misc/altera-a10sr-monitor.c
F: include/linux/mfd/altera-a10sr.h
ALTERA TRIPLE SPEED ETHERNET DRIVER
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 64971ba..f42d459 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -766,6 +766,13 @@ config PANEL_BOOT_MESSAGE
An empty message will only clear the display at driver init time. Any other
printf()-formatted message is valid with newline and escape codes.
+config ALTERA_A10SR_MONITOR
+ bool "Altera Arria10 System Resource Monitor"
+ depends on MFD_ALTERA_A10SR
+ help
+ This enables the System Resource monitor driver for the Altera
+ Arria10 DevKit.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 3198336..9f6e77a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -43,6 +43,7 @@ obj-y += ti-st/
obj-y += lis3lv02d/
obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
+obj-$(CONFIG_ALTERA_A10SR_MONITOR) += altera-a10sr-monitor.o
obj-$(CONFIG_INTEL_MEI) += mei/
obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
diff --git a/drivers/misc/altera-a10sr-monitor.c b/drivers/misc/altera-a10sr-monitor.c
new file mode 100644
index 0000000..838ec2c
--- /dev/null
+++ b/drivers/misc/altera-a10sr-monitor.c
@@ -0,0 +1,176 @@
+/*
+ * Altera Arria10 DevKit System Resource Chip Monitor Driver
+ *
+ * Author: Thor Thayer <tthayer@opensource.altera.com>
+ *
+ * Copyright Intel Corporation (C) 2014-2016. All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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/>.
+ *
+ * Monitor driver for the Altera Arria10 MAX5 System Resource Chip
+ * Adapted from ics932s401.c
+ */
+
+#include <linux/err.h>
+#include <linux/mfd/altera-a10sr.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+struct altr_a10sr_regs {
+ struct regmap *regmap;
+ struct attribute_group attr_grp;
+};
+
+static ssize_t a10sr_show(struct device *dev,
+ struct device_attribute *devattr, char *buf);
+static ssize_t a10sr_store(struct device *dev,
+ struct device_attribute *devattr, const char *buf,
+ size_t count);
+
+/* Define FS entries */
+static DEVICE_ATTR(max5_version, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_led, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_button, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_button_irq, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_pg1, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_pg2, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_pg3, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_fmcab, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_hps_resets, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_per_resets, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_sfpa, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_sfpb, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_i2c_master, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_wm_rst, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_wm_rst_key, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_pmbus, 0644, a10sr_show, a10sr_store);
+
+static struct attribute *altr_a10sr_attr[] = {
+ &dev_attr_max5_version.attr,
+ &dev_attr_max5_led.attr,
+ &dev_attr_max5_button.attr,
+ &dev_attr_max5_button_irq.attr,
+ &dev_attr_max5_pg1.attr,
+ &dev_attr_max5_pg2.attr,
+ &dev_attr_max5_pg3.attr,
+ &dev_attr_max5_fmcab.attr,
+ &dev_attr_max5_hps_resets.attr,
+ &dev_attr_max5_per_resets.attr,
+ &dev_attr_max5_sfpa.attr,
+ &dev_attr_max5_sfpb.attr,
+ &dev_attr_max5_i2c_master.attr,
+ &dev_attr_max5_wm_rst.attr,
+ &dev_attr_max5_wm_rst_key.attr,
+ &dev_attr_max5_pmbus.attr,
+ NULL
+};
+
+static const struct attribute_group a10sr_attr_group = {
+ .attrs = altr_a10sr_attr,
+};
+
+static ssize_t a10sr_show(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ int i, ret;
+ unsigned int val;
+ struct altr_a10sr_regs *a10sr_regs = dev_get_drvdata(dev);
+
+ for (i = 0; i < ARRAY_SIZE(altr_a10sr_attr); i++) {
+ if (devattr == (struct device_attribute *)altr_a10sr_attr[i])
+ break;
+ }
+
+ if (i >= ARRAY_SIZE(altr_a10sr_attr))
+ return -EINVAL;
+
+ /* Shift because LS bit set by regmap for Read */
+ i <<= 1;
+ ret = regmap_read(a10sr_regs->regmap, i, &val);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "0x%X\n", val);
+}
+
+static ssize_t a10sr_store(struct device *dev,
+ struct device_attribute *devattr, const char *buf,
+ size_t count)
+{
+ struct altr_a10sr_regs *a10sr_regs = dev_get_drvdata(dev);
+ unsigned long val;
+ int i, ret;
+
+ ret = kstrtol(buf, 0, &val);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < ARRAY_SIZE(altr_a10sr_attr); i++) {
+ if (devattr == (struct device_attribute *)altr_a10sr_attr[i])
+ break;
+ }
+ if (i >= ARRAY_SIZE(altr_a10sr_attr))
+ return -EINVAL;
+
+ /* Shift because LS bit cleared by regmap for Write */
+ i <<= 1;
+ ret = regmap_write(a10sr_regs->regmap, i, val);
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
+static int altr_a10sr_regs_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct altr_a10sr_regs *a10regs;
+ struct altr_a10sr *a10sr = dev_get_drvdata(pdev->dev.parent);
+
+ a10regs = devm_kzalloc(&pdev->dev, sizeof(*a10regs), GFP_KERNEL);
+ if (!a10regs)
+ return -ENOMEM;
+
+ a10regs->regmap = a10sr->regmap;
+ a10regs->attr_grp = a10sr_attr_group;
+
+ platform_set_drvdata(pdev, a10regs);
+
+ return sysfs_create_group(&pdev->dev.kobj, &a10sr_attr_group);
+}
+
+static int altr_a10sr_regs_remove(struct platform_device *pdev)
+{
+ struct altr_a10sr_regs *a10regs = platform_get_drvdata(pdev);
+
+ sysfs_remove_group(&pdev->dev.kobj, &a10regs->attr_grp);
+
+ return 0;
+}
+
+static const struct of_device_id altr_a10sr_regs_of_match[] = {
+ { .compatible = "altr,a10sr-monitor" },
+ { },
+};
+
+static struct platform_driver altr_a10sr_regs_driver = {
+ .probe = altr_a10sr_regs_probe,
+ .remove = altr_a10sr_regs_remove,
+ .driver = {
+ .name = "altr_a10sr_monitor",
+ .of_match_table = altr_a10sr_regs_of_match,
+ },
+};
+
+builtin_platform_driver(altr_a10sr_regs_driver);
--
1.9.1
^ permalink raw reply related
* [PATCHv2 3/4] mfd: altr-a10sr: Add Arria10 SR Monitor
From: tthayer at opensource.altera.com @ 2016-10-27 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477598426-28125-1-git-send-email-tthayer@opensource.altera.com>
From: Thor Thayer <tthayer@opensource.altera.com>
Add the Altera Arria10 DevKit System Resource Monitor functionality
to the MFD device.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
---
v2 Change from -mon to -monitor for clarity
---
drivers/mfd/altera-a10sr.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/altera-a10sr.c b/drivers/mfd/altera-a10sr.c
index 06e1f7f..30de652 100644
--- a/drivers/mfd/altera-a10sr.c
+++ b/drivers/mfd/altera-a10sr.c
@@ -33,6 +33,10 @@
.name = "altr_a10sr_gpio",
.of_compatible = "altr,a10sr-gpio",
},
+ {
+ .name = "altr_a10sr_monitor",
+ .of_compatible = "altr,a10sr-monitor",
+ },
};
static bool altr_a10sr_reg_readable(struct device *dev, unsigned int reg)
--
1.9.1
^ permalink raw reply related
* [PATCHv2 4/4] ARM: socfpga: dts: Add Monitor to A10-SR MFD
From: tthayer at opensource.altera.com @ 2016-10-27 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477598426-28125-1-git-send-email-tthayer@opensource.altera.com>
From: Thor Thayer <tthayer@opensource.altera.com>
Add the Monitor functionality to the Arria10 DevKit
System Resource chip.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
---
v2 Change from -mon to -monitor for clarity.
---
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi b/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
index eb00ae3..61a5f42 100644
--- a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
@@ -121,6 +121,10 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ a10sr_monitor {
+ compatible = "altr,a10sr-monitor";
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [alsa-devel] [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Maxime Ripard @ 2016-10-27 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027171325.d68baa5ff51da4921ff8b94d@free.fr>
On Thu, Oct 27, 2016 at 05:13:25PM +0200, Jean-Francois Moine wrote:
> On Mon, 24 Oct 2016 14:34:49 +0200
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Sun, Oct 23, 2016 at 09:45:03AM +0200, Jean-Francois Moine wrote:
> > > On Sun, 23 Oct 2016 09:33:16 +0800
> > > Chen-Yu Tsai <wens@csie.org> wrote:
> > >
> > > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > > - it handles the H3
> > > >
> > > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > > the newer SoCs.
> > > >
> > > > > - it creates the sound card (with sun4i-i2s, the sound card is created
> > > > > by the CODECs)
> > > >
> > > > I think this is wrong. I2S is only the DAI. You typically have a separate
> > > > platform driver for the whole card, or just use simple-card.
> > >
> > > An other device is not needed. The layout is simple:
> > > I2S_controller (CPU DAI) <-> HDMI_CODEC (CODEC DAI)
> > > The HDMI CODEC is supported by the HDMI video driver (only one device),
> > > so, it cannot be the card device.
> > > ASoC does not use the CPU DAI device (I2S_controller), so, it is
> > > natural to use it to handle the card.
> >
> > Still, duplicating the driver is not the solution. I agree with
> > Chen-Yu that we want to leverage the driver that is already there.
>
> Hi Maxime and Chen-Yu,
>
> After looking at the sun4i-i2s, I found 2 solutions for re-using its
> code in the DE2 HDMI context:
>
> 1) either to split the sun4i-i2s driver into common I/O functions and
> slave CPU DAI,
>
> 2) or to move the sun4i-i2s into a master CPU DAI.
>
> (
> some explanation about 'master' and 'slave': the master is the
> component the device of which is also the sound card.
> As the sound card uses the 'drvdata' of the device, this drvdata pointer
> cannot be used by the master.
> In the actual implementations:
> - sun4i-i2s
> master: card dev = codec dev, drvdata -> card
> slave: i2s dev (CPU DAI), drvdata -> i2s data
> - sun8i-i2s
> master: card dev = i2s dev (CPU DAI), drvdata -> card
> slave: codec dev (hdmi), drvdata -> codec data (audio/video)
> )
>
> In the case 1, there is no functional change, just a source split.
> The sun8i-i2s will then use the common I/O functions.
>
> In the case 2, the CODECs using the sun4i-i2s would have to move to
> slave CODEC DAI, i.e. the card is created by the sun4i-i2s code.
> In the 4.9, there is only one codec (sun4i-codec), so, the change
> is just to move the card creation and the use of drvdata in both
> codes.
I think you're mistaken. sun4i-codec has nothing to do with the I2S
driver. It's a driver for the (poorly named) Allwinner's Audio Codec
which features it's own DAI and Codec directly into the SoC.
The DAI being different from the I2S one.
However, we want to use any codec driver with the i2s driver,
including those in sound/soc/codecs, and we already have drivers for
them.
So I'm not sure either solution is a good one. Why not just make the
HDMI part a codec itself, and use the i2s driver as the CPU DAI, like
any other codec?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161027/7681c7e9/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes
From: John Stultz @ 2016-10-27 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKfTPtB0FtGbm4C5z+LJizrsHikKt_BGFti5XY+LN3w7zO1Vjw@mail.gmail.com>
On Thu, Oct 27, 2016 at 6:56 AM, Vincent Guittot
<vincent.guittot@linaro.org> wrote:
>
> My hikey board failed to detect and mount sdcard with v4.9-rc1 and i
> have bisected the issue to this patch. Once reverted, the sdcard is
> detected again.
Hrm.. I've not seen this w/ my v4.9-rc2 based tree, and I don't have
any mmc patches there.
Can you send me your .config and point me to any other patches you're
running with? Also do you have any details about the card in case its
card specific?
Guodong: Is there any bootloader dependency on that change?
thanks
-john
^ permalink raw reply
* [PATCH next 1/2] media: mtk-mdp: fix video_device_release argument
From: Vincent Stehlé @ 2016-10-27 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473340146-6598-4-git-send-email-minghsiu.tsai@mediatek.com>
video_device_release() takes a pointer to struct video_device as argument.
Fix two call sites where the address of the pointer is passed instead.
Fixes: c8eb2d7e8202fd9c ("[media] media: Add Mediatek MDP Driver")
Signed-off-by: Vincent Stehl? <vincent.stehle@laposte.net>
Cc: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index 9a747e7..4a9e3e9d 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -1267,13 +1267,13 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
err_vdev_register:
v4l2_m2m_release(mdp->m2m_dev);
err_m2m_init:
- video_device_release(&mdp->vdev);
+ video_device_release(mdp->vdev);
return ret;
}
void mtk_mdp_unregister_m2m_device(struct mtk_mdp_dev *mdp)
{
- video_device_release(&mdp->vdev);
+ video_device_release(mdp->vdev);
v4l2_m2m_release(mdp->m2m_dev);
}
--
2.9.3
^ permalink raw reply related
* [PATCH next 2/2] media: mtk-mdp: NULL-terminate mtk_mdp_comp_dt_ids
From: Vincent Stehlé @ 2016-10-27 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027202325.20680-1-vincent.stehle@laposte.net>
The mtk_mdp_comp_dt_ids[] array should be NULL-terminated; add therefore an
empty entry in the end.
Fixes: c8eb2d7e8202fd9c ("[media] media: Add Mediatek MDP Driver")
Signed-off-by: Vincent Stehl? <vincent.stehle@laposte.net>
Cc: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 40a229d..53296e2 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -50,7 +50,8 @@ static const struct of_device_id mtk_mdp_comp_dt_ids[] = {
}, {
.compatible = "mediatek,mt8173-mdp-wrot",
.data = (void *)MTK_MDP_WROT
- }
+ },
+ { },
};
static const struct of_device_id mtk_mdp_of_ids[] = {
--
2.9.3
^ permalink raw reply related
* [RFC PATCH 0/5] Add an overlay manager to handle board capes
From: Hans de Goede @ 2016-10-27 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKTMjj0x6Zq3t5GsWvAC1qN10r333v9uGXkJq_DjioRmA@mail.gmail.com>
Hi,
On 27-10-16 19:30, Rob Herring wrote:
> On Thu, Oct 27, 2016 at 10:13 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 27-10-16 15:41, Rob Herring wrote:
>>>
>>> Please Cc the maintainers of drivers/of/.
>>>
>>> + Frank R, Hans, Dmitry S
>>>
>>> On Wed, Oct 26, 2016 at 9:57 AM, Antoine Tenart
>>> <antoine.tenart@free-electrons.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Many boards now come with dips and compatible capes; among others the
>>>> C.H.I.P, or Beaglebones. All these boards have a kernel implementing an
>>>> out-of-tree "cape manager" which is used to detected capes, retrieve
>>>> their description and apply a corresponding overlay. This series is an
>>>> attempt to start a discussion, with an implementation of such a manager
>>>> which is somehow generic (i.e. formats or cape detectors can be added).
>>>> Other use cases could make use of this manager to dynamically load dt
>>>> overlays based on some input / hw presence.
>>>
>>>
>>> I'd like to see an input source be the kernel command line and/or a DT
>>> chosen property. Another overlay manager was proposed not to long
>>> ago[1] as well. There's also the Allwinner tablet use case from Hans
>>> where i2c devices are probed and detected. That's not using overlays
>>> currently, but maybe could.
>>
>>
>> Actually I'm currently thinking in a different direction, which I
>> think will be good for the boards where some ICs are frequently
>> replaced by 2nd (and 3th and 4th) sources, rather then that we're
>> dealing with an extension connector with capes / daughter boards.
>>
>> Although there is some overlap I'm starting to think that we need to
>> treat these 2 cases differently. Let me quickly copy and paste
>> the basic idea I've for the 2nd source touchscreen / accelerometer
>> chip case:
>>
>> """
>> The kernel actually already has a detect() method in struct i2c_driver,
>> we could use that (we would need to implement it in drivers which do not
>> have it yet). Note on second thought it seems it may be better to use
>> probe() for this, see below.
>>
>> Then we could have something like this in dt:
>>
>> &i2c0 {
>> touchscreen1: gsl1680 at 40 {
>> reg = <0x40>;
>> compatible = "silead,gsl1680";
>> enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
>> status = "disabled";
>> };
>>
>> touchscreen2: ektf2127 at 15 {
>> reg = <0x15>;
>
> Do you ever have different devices with the same address? That would
> be somewhat problematic as really these should be
> "touchscreen@<addr>".
Yes that happens (sometimes).
>
>> compatible = "elan,ektf2127";
>> enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
>> status = "disabled";
>> };
>>
>> i2c-probe-stop-at-first-match-0 = <&touchscreen1>, <&touchscreen2>;
>> i2c-probe-stop-at-first-match-1 = <&accelerometer1>, <&accelerometer2>;
>> }
>>
>> Which would make the i2c subsys call detect (*) on each device, until
>> a device is found. Likewise we could have a "i2c-probe-all" property
>> which also walks a list of phandles but does not stop on the first
>> match.
>>
>> ...
>>
>> *) Yes this sounds Linux specific, but it really is just "execute
>> to-be-probed
>> device compatible specific detection method"
>> """
>
> Yeah, not a fan of these properties at first glance. Why can't you
> just fail probe on the non-existent devices?
That is possible and in the other thread on this there are some
links to some boards which actually already do this, but from a dt
pov it feels wrong. If we know only one of a set of options will
ever be there we ought to describe things like this in the dt.
Functionality wise this has 2 advantages:
1) We stop probing needlessly once a device is found, in some
cases the majority of the board variants has dev a, and some
have dev b / c. Then putting a first in the to-probe list will
save probing b / c on most boards.
2) Not all i2c chips are easily identifiable, so in some cases
one may want to put dev x as last to probe, because the
probe solely consists of: "Does something ack i2c transfers
at this address".
>> This does not 100% solve all q8 issues (see the "Add Allwinner Q8 tablets
>> hardware manager" thread), but does solve quite a bit of the use-case
>> and this matches what many vendor os-images (typically android) are
>> actually doing for these kind of boards.
>
> BTW, I've been meaning to ask you if you are looking at the Android
> side of things as well?
No, I purely use android os images / SDKs as a source of how the
hw works, I do not have any intentions to try and get android up
and running with mainline on these boards.
>> As for the bits this does not solve, those are mostly board specific details
>> which cannot be probed at all, and on x86 are typically solved in the device
>> driver by doing a dmi check to identify the board and then apply a board
>> specific workaround in the driver.
>>
>> I've come to believe that we should similarly delegate dealing this to
>> device
>> drivers in the devicetree case. Note that dt should still of course fully
>> describe the hardware for normal hardware, the driver would just need to
>> care
>> about weird board quirks in certain exceptions.
>
> Which is fine IMO, though I do think we should look at those cases
> carefully to ensure they stay the exception.
Ack.
>> A more interesting problem here is that dt does not have something like
>> DMI, there is the machine compatible, but that typically does not contain
>> board revision info (where as DMI often does). I believe that this is
>> actually something which should be fixed at the bootloader level
>> have it prepend a new machine compatible which contains revision info.
>>
>> Hmm, if we make the bootloader prepend a new machine compatible which
>> contains
>> revision info, we could then trigger quirks on this and in some cases avoid
>> the need for dealing with board quirks in the driver ...
>
> That would work. Board and chip versions both need better handling in
> kernel IMO.
>
> QCom has a whole scheme around version numbering in compatible
> strings. (Unfortunately, bootloaders only support their previous way
> of doing things.)
>
>> Note this is all very specific to dealing with board (revision) variants,
>> for add-ons having the bootloader add info to the machine compatible does
>> not seem the right solution.
>
> Agreed.
Regards,
Hans
^ permalink raw reply
* [PATCH 4/5] net: ethernet: bgmac: add NS2 support
From: Jon Mason @ 2016-10-27 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eff0c717-ec4b-1dce-992a-ad5e958800f5@gmail.com>
On Wed, Oct 26, 2016 at 02:50:39PM -0700, Florian Fainelli wrote:
> On 10/26/2016 12:36 PM, Jon Mason wrote:
> > Add support for the variant of amac hardware present in the Broadcom
> > Northstar2 based SoCs. Northstar2 requires an additional register to be
> > configured with the port speed/duplexity (NICPM). This can be added to
> > the link callback to hide it from the instances that do not use this.
> > Also, the bgmac_chip_reset() was intentionally removed to prevent the
> > resetting of the chip to the default values on open. Finally, clearing
> > of the pending interrupts on init is required due to observed issues on
> > some platforms.
> >
> > Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> > ---
>
> > +static void bgmac_nicpm_speed_set(struct net_device *net_dev)
> > +{
> > + struct bgmac *bgmac = netdev_priv(net_dev);
> > + u32 val;
> > +
> > + if (!bgmac->plat.nicpm_base)
> > + return;
> > +
> > + val = NICPM_IOMUX_CTRL_INIT_VAL;
> > + switch (bgmac->net_dev->phydev->speed) {
> > + default:
> > + pr_err("Unsupported speed. Defaulting to 1000Mb\n");
> > + case SPEED_1000:
> > + val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> > + break;
> > + case SPEED_100:
> > + val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> > + break;
> > + case SPEED_10:
> > + val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> > + break;
> > + }
> > +
> > + writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
> > +
> > + usleep_range(10, 100);
>
> Does not seem like a good idea, do you need that sleep?
Oops, that's not supposed to be there. Removed.
> > +
> > + bgmac_adjust_link(bgmac->net_dev);
> > +}
> > +
> > static int platform_phy_connect(struct bgmac *bgmac)
> > {
> > struct phy_device *phy_dev;
> >
> > - phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
> > - bgmac_adjust_link);
> > + if (bgmac->plat.nicpm_base)
> > + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> > + bgmac->dev->of_node,
> > + bgmac_nicpm_speed_set);
> > + else
> > + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> > + bgmac->dev->of_node,
> > + bgmac_adjust_link);
> > if (!phy_dev) {
> > dev_err(bgmac->dev, "Phy connect failed\n");
> > return -ENODEV;
> > }
> >
> > + if (bgmac->feature_flags & BGMAC_FEAT_LANE_SWAP)
> > + phy_dev->dev_flags |= PHY_BRCM_EXP_LANE_SWAP;
> > +
> > return 0;
> > }
> >
> > @@ -140,6 +188,9 @@ static int bgmac_probe(struct platform_device *pdev)
> >
> > platform_set_drvdata(pdev, bgmac);
> >
> > + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap"))
> > + bgmac->feature_flags |= BGMAC_FEAT_LANE_SWAP;
> > +
> > /* Set the features of the 4707 family */
> > bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
> > bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
> > @@ -182,6 +233,14 @@ static int bgmac_probe(struct platform_device *pdev)
> > if (IS_ERR(bgmac->plat.idm_base))
> > return PTR_ERR(bgmac->plat.idm_base);
> >
> > + regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
> > + if (regs) {
> > + bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
> > + regs);
> > + if (IS_ERR(bgmac->plat.nicpm_base))
> > + return PTR_ERR(bgmac->plat.nicpm_base);
> > + }
> > +
> > bgmac->read = platform_bgmac_read;
> > bgmac->write = platform_bgmac_write;
> > bgmac->idm_read = platform_bgmac_idm_read;
> > @@ -213,6 +272,7 @@ static int bgmac_remove(struct platform_device *pdev)
> > static const struct of_device_id bgmac_of_enet_match[] = {
> > {.compatible = "brcm,amac",},
> > {.compatible = "brcm,nsp-amac",},
> > + {.compatible = "brcm,ns2-amac",},
> > {},
> > };
> >
> > diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> > index 38876ec..1796208 100644
> > --- a/drivers/net/ethernet/broadcom/bgmac.c
> > +++ b/drivers/net/ethernet/broadcom/bgmac.c
> > @@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
> > /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
> > static void bgmac_chip_init(struct bgmac *bgmac)
> > {
> > + /* Clear any erroneously pending interrupts */
> > + bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
> > +
> > /* 1 interrupt per received frame */
> > bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
> >
> > @@ -1158,8 +1161,6 @@ static int bgmac_open(struct net_device *net_dev)
> > struct bgmac *bgmac = netdev_priv(net_dev);
> > int err = 0;
> >
> > - bgmac_chip_reset(bgmac);
> > -
>
> Is this removal intentional? Maybe it should be special cased with
> checking for a NS2 BGMAC instance and not do it in that case?
The reset seems completely unnecessary. There is already 2 resets in
the probe routine, another reset serves no purpose. I can add it
back, as it does not seem to have the negative effect I was seeing
before.
Of course, if I remove this one I should remove the reset in the close
too (which seems even more unnecessary, but I didn't remove it).
Thanks,
Jon
> --
> Florian
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Hans de Goede @ 2016-10-27 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9B288597-7812-459D-A5C7-B61107751DA6@konsulko.com>
Hi,
On 27-10-16 17:52, Pantelis Antoniou wrote:
> Hi Hans,
<snip>
>> Right, so again I think we need to split the discussion in 2 steps:
>>
>> 1) How do we apply the fixups, currently I'm using free-form changes
>> done from C-code. I can envision moving to something like the quirk
>> mechanism suggested by Pantelis in the past. Note this is not a perfect
>> fit for my rather corner-case use-case, but I can understand that in
>> general you want the variants to be described in dt, and activated
>> in some way, rather then have c-code make free-form changes to the dt
>>
>
> We?ve had this discussion before, so I guess here it goes again.
>
> I think the biggest objection is the programmatic way of applying
> every quirk by ?hand?.
>
> If there was a way to keep the probing mechanism but just spit out
> a ?model? number we could reasonably map it to an overlay to apply
> with a generic overlay manager.
>
> From an internal s/w standpoint having an expansion board or soldered
> parts makes no difference.
I disagree, with soldered parts it often is the board has
one of "accelerometer a", "b" or "c", where in the simple case
my suggested i2c-probe-stop-at-first-match property will
just work for a new board by creating a new dtb without needing any
kernel changes, where as your suggested model-string generator
C-code module would need updating.
I think that there is a need for both really.
>> 2) How do we select which fixups to apply. Again I can understand
>> you wanting some well defined mechanism for this, but again my
>> use-case is special and simply does not allow for this as there
>> is no id-eeprom to read or some such.
>>
>
> Yes there is no EEPROM but you might be able to map probing results to
> a fake ?model? number.
>
> Let me expand a bit:
>
> Assume that you have a number of probing steps, for example A, B, C each
> returning true or false, and C being executed only when B is ?true? you
> could do this to generate a bit field that identifies it.
>
> For example let?s assume that model FOO?s probing steps are
>
> A false, B true, C false -> 010
>
> Model?s BAR
>
> A true, B false, C don?t care -> 10x
>
> Mapping these to models could be
>
> Model FOO, (010 & 111) == 010 (all three probing steps must match)
>
> Model BAR, (10x & 110) = 100 (the first two probing steps must match)
Interesting this is actually the same direction my thoughts on this
lead me in my reply in the other thread on this started by
Antoine Tenart.
Only difference is that I suggested putting the model-string
generation in the bootloader, so it will just be there when the kernel
boots. But I agree that given things like upgradability having
the model-string generation code in the kernel is better.
<snip>
Regards,
Hans
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Hans de Goede @ 2016-10-27 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ-oXjRJrs77yE-skpZ-V4e=rdhRyfNve9bibf1VOaZYy2=tRA@mail.gmail.com>
Hi,
On 27-10-16 19:31, Pierre-Hugues Husson wrote:
> 2016-10-27 16:53 GMT+02:00 Hans de Goede <hdegoede@redhat.com>:
<snip>
>> We could just have:
>>
>> i2c-probe-stop-at-first-match-0 = <&touchscreen1>, <&touchscreen2>,
>> <&touchscreen3>;
>> i2c-probe-stop-at-first-match-1 = <&accelerometer1>,
>> <&accelerometer2>;
>>
>> And have the i2c bus code look for an i2c-probe-stop-at-first-match-[i++]
>> property
>> until it is not found. Having a child-node with its own compatible for this
>> feels wrong, as it uses a hierarchy where there really is none.
> Ok, looks much better indeed.
> I had one case where accelerometers could be on either i2c1 or i2c5.
> Do you think this could be handled as well, or this makes things much
> more complicated to fit in the i2c driver?
Handling that is easy, just add a i2c-probe-stop-at-first-match to
both busses (with separate child nodes to be probed under each bus),
the on one bus the probe-code will just read the end of the list
and stop, I believe we should not treat that as an error anyways
(even if there is only 1 bus).
>
>> So this would require us to be able to filter (to use your example)
>> on if another i2c device is found and on which address it is found,
>> that does not even take the rda559x check into account and is
>> going to cause interesting ordering issues, how do we know when
>> we can actually do the filtering if some of the variables we are
>> filtering on are set by other auto-detected paths. Which auto-detect /
>> i2c-probe-stop-at-first-match list do we execute first ? Worse
>> actually for accelerometer orientation I will likely need to
>> set the mount-matrix based on the detected touchscreen ...
>>
>> The rda559x here is a sdio wifi chip, which is also connected to the
>> i2c, and currently is detected through i2c to be able to separately
>> identify 2 q8 boards which share the same touchscreen + accelerometer
>> combination and who knows what other checks I or other people can
>> come up with to differentiate board variants which do not have
>> a simple eeprom to uniquely id them.
>>
>> So as said before, no this cannot be all done in dt without
>> adding a turing complete language to dt, and that is just to
>> select which touchscreen_variant to use.
> Ok, now that I understand the scope of your needs.
> I agree with you, this needs a (close to) turing complete language.
> I'm still not really happy about doing it in a driver, but I agree the
> full scope you need is scarce enough.
> Assuming this is done in a driver, there would need to be some
> plumbing between i2c-probe-stop-at-first-match, device's probe
> function and your driver, so that your driver only does the various
> if/cases and DT changes, but there is no actual device communication
> done in that driver.
Ah, no I meant dealing with this in the actual device driver,
not in some special intermediate driver, just like the actual x86
device drivers (sometimes) apply quirks based on board DMI strings.
<snip>
Regards,
Hans
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: John Syne @ 2016-10-27 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026084811.GI8574@dell>
>
> On Oct 26, 2016, at 1:48 AM, Lee Jones <lee.jones@linaro.org> wrote:
>
> On Tue, 25 Oct 2016, John Syne wrote:
>>> On Oct 24, 2016, at 11:38 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>> On Mon, 24 Oct 2016, John Syne wrote:
>>>>> On Oct 24, 2016, at 11:01 PM, John Syne <john3909@gmail.com> wrote:
>>>>>> On Oct 24, 2016, at 10:52 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>>>>
>>>>>> On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
>>>>>>>>> On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>>>>>>>
>>>>>>>>> Increase ADC reference clock from 3MHz to 24MHz so that the
>>>>>>>>> sampling rates goes up from 100K samples per second to 800K
>>>>>>>>> samples per second on AM335x and AM437x SoC.
>>>>>>>>>
>>>>>>>>> Also increase opendelay for touchscreen configuration to
>>>>>>>>> equalize the increase in ADC reference clock frequency,
>>>>>>>>> which results in the same amount touch events reported via
>>>>>>>>> evtest on AM335x GP EVM.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> This patch depends on ADC DMA patch series [1]
>>>>>>>>>
>>>>>>>>> Without DMA support, when ADC ref clock is set at 24MHz, I am
>>>>>>>>> seeing fifo overflow as CPU is not able to pull the ADC samples.
>>>>>>>>> This answers that DMA support is must for ADC to consume the
>>>>>>>>> samples generated at 24MHz with no open, step delay or
>>>>>>>>> averaging with patch [2].
>>>>>>>>>
>>>>>>>>> Measured the performance with the iio_generic_buffer with the
>>>>>>>>> patch [3] applied
>>>>>>>>>
>>>>>>>>> [1] - http://www.spinics.net/lists/devicetree/msg145045.html
>>>>>>>>> [2] - http://pastebin.ubuntu.com/23357935/
>>>>>>>>> [3] - http://pastebin.ubuntu.com/23357939/
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
>>>>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>>>>>>>>> index b9a53e0..96c4207 100644
>>>>>>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>>>>>>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>>>>>>>>> @@ -90,7 +90,7 @@
>>>>>>>>> /* Delay register */
>>>>>>>>> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
>>>>>>>>> #define STEPDELAY_OPEN(val) ((val) << 0)
>>>>>>>>> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
>>>>>>> Wouldn?t this be better to add this to the devicetree?
>>>>>>>
>>>>>>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
>>>>>>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
>>>>>>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>>>>>>
>>>>>> For a touch screen, there is not need to change in these parameter
>>>>>> settings, so my opinion is to keep it as is. Or am I missing something?
>>>>> I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen.
>>>>
>>>> Here is a DT overlay were this gets using on the BeagleBoneBlack.
>>>>
>>>> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
>>>>
>>>> Besides, these DT features are already implemented in the driver so it is just a matter of adding these entries to the am33xx.dtsi & am4372.dtsi, which you modified in this patch series.
>>>
>>> This looks like configuration, no?
>>>
>>> DT should be used to describe the hardware.
>> You may be right, but how is this different to setting the baud rate on a serial channel or sampling rate on a audio channel? Looking through the DT, there are many configuration settings, so I?m not sure what is the correct way to handle this. Surely it is better to handle this in DT vs hard coding these settings?
>
> I think setting the UART baud rate is also an invalid DT entry.
>
> It's okay to list all of the options in DT, but to actually select
> one, that should be done either in userspace or as a kernel option.
> Perhaps as a Kconfig selection.
Yeah, this has been inconsistent for a long time. My only point was that these DT parameters had already been implemented in the ti_am335x_adc KM and I thought that this was better than hard coding these settings. Implementing this in Kconfig means rebuilding the KM, which isn?t desirable. Perhaps this should be done via sysfs attributes so as you say, a userspace app can configure this driver. I guess the DT code in ti_am335x_adc.c should be removed.
Regards,
John
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/5] Documentation: devicetree: net: add NS2 bindings to amac
From: Jon Mason @ 2016-10-27 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027091757.GC12841@lunn.ch>
On Thu, Oct 27, 2016 at 11:17:57AM +0200, Andrew Lunn wrote:
> On Wed, Oct 26, 2016 at 03:35:58PM -0400, Jon Mason wrote:
> > Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> > ---
> > Documentation/devicetree/bindings/net/brcm,amac.txt | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
> > index ba5ecc1..f92caee 100644
> > --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
> > +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
> > @@ -2,15 +2,18 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
> > -------------------------------------------------------------
> >
> > Required properties:
> > - - compatible: "brcm,amac" or "brcm,nsp-amac"
> > + - compatible: "brcm,amac", "brcm,nsp-amac", or "brcm,ns2-amac"
> > - reg: Address and length of the GMAC registers,
> > Address and length of the GMAC IDM registers
> > + Address and length of the NIC Port Manager registers (optional)
> > - reg-names: Names of the registers. Must have both "amac_base" and
> > - "idm_base"
> > + "idm_base". "nicpm_base" is optional (required for NS2)
> > - interrupts: Interrupt number
> >
> > Optional properties:
> > - mac-address: See ethernet.txt file in the same directory
> > +- brcm,enet-phy-lane-swap:
> > + boolean; Swap the PHY lanes (needed on some SKUs of NS2)
>
> Maybe i'm missing something here, but the patch to the PHY swapped the
> lanes. This seems to be a PHY property, not a MAC property. And it
> swapped them unconditionally....
It swapped them based on (from patch 1/5)
if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810 &&
phydev->dev_flags & PHY_BRCM_EXP_LANE_SWAP)
That flag is being set in the driver based on whether the lanes need
to be swapped (which depends on the SKU of NS2). The only SKU of NS2
we have upstream right now has it swapped, but one that should be
pushed out in the next few weeks will not have this flag present.
There is no way to detect it, and having a separate compat string
seemed overkill.
Thanks,
Jon
>
> Andrew
^ permalink raw reply
* [kernel-hardening] Re: [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Kees Cook @ 2016-10-27 21:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027145450.GB3762@e104818-lin.cambridge.arm.com>
On Thu, Oct 27, 2016 at 7:54 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Fri, Sep 30, 2016 at 11:42:02AM -0700, Kees Cook wrote:
>> On Thu, Sep 29, 2016 at 3:44 PM, Sami Tolvanen <samitolvanen@google.com> wrote:
>> > On Thu, Sep 15, 2016 at 05:20:45PM +0100, Mark Rutland wrote:
>> >> Likewise, how do we handle __flush_cache_user_range and
>> >> flush_icache_range? Some callers (e.g. __do_compat_cache_op) pass in
>> >> __user addresses.
>> >
>> > Also EXEC_USERSPACE in lkdtm passes a user space address to flush_icache_range
>> > and causes the process to hang when I tested these patches on HiKey.
>> >
>> > Adding uaccess_{enable,disable}_not_uao to __flush_cache_user_range appears to
>> > fix the problem.
>>
>> I had a thought just now on this: is lkdtm maybe doing the wrong thing
>> here? i.e. should lkdtm be the one do to the uaccess_en/disable
>> instead of flush_icache_range() itself, since it's the one abusing the
>> API?
>
> (preparing the v4 series)
>
> I think lkdtm is using the API incorrectly here. The documentation for
> flush_icache_range() (Documentation/cachetlb.txt) states that it is to
> be used on kernel addresses. Even with uaccess_enable/disable in lkdtm,
> faults on user space can still happen and the flush_icache_range()
> function must be able to handle them. It happens to work on arm64
> because of the fall through __flush_cache_user_range() but that's not
> guaranteed on other architectures.
>
> A potential solution is to use access_process_vm() and let the arch code
> handle the cache maintenance automatically:
Ah, perfect! I'll give this a spin, thanks!
-Kees
> ---------------------8<--------------------------------
> From fcbb7c9c30daf9bfc2a215ec10dba79c109ab835 Mon Sep 17 00:00:00 2001
> From: Catalin Marinas <catalin.marinas@arm.com>
> Date: Thu, 27 Oct 2016 15:47:20 +0100
> Subject: [PATCH] lkdtm: Do not use flush_icache_range() on user addresses
>
> The flush_icache_range() API is meant to be used on kernel addresses
> only as it may not have the infrastructure (exception entries) to handle
> user memory faults.
>
> The lkdtm execute_user_location() function tests the kernel execution of
> user space addresses by mmap'ing an anonymous page, copying some code
> together with cache maintenance and attempting to run it. However, the
> cache maintenance step may fail because of the incorrect API usage
> described above. The patch changes lkdtm to use access_process_vm() for
> copying the code into user space which would take care of the necessary
> cache maintenance.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> drivers/misc/lkdtm_perms.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/lkdtm_perms.c b/drivers/misc/lkdtm_perms.c
> index 45f1c0f96612..c7635a79341f 100644
> --- a/drivers/misc/lkdtm_perms.c
> +++ b/drivers/misc/lkdtm_perms.c
> @@ -60,15 +60,18 @@ static noinline void execute_location(void *dst, bool write)
>
> static void execute_user_location(void *dst)
> {
> + int copied;
> +
> /* Intentionally crossing kernel/user memory boundary. */
> void (*func)(void) = dst;
>
> pr_info("attempting ok execution at %p\n", do_nothing);
> do_nothing();
>
> - if (copy_to_user((void __user *)dst, do_nothing, EXEC_SIZE))
> + copied = access_process_vm(current, (unsigned long)dst, do_nothing,
> + EXEC_SIZE, FOLL_WRITE);
> + if (copied < EXEC_SIZE)
> return;
> - flush_icache_range((unsigned long)dst, (unsigned long)dst + EXEC_SIZE);
> pr_info("attempting bad execution at %p\n", func);
> func();
> }
--
Kees Cook
Nexus Security
^ permalink raw reply
* [PATCH 2/5] Documentation: devicetree: net: add NS2 bindings to amac
From: Florian Fainelli @ 2016-10-27 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027212106.GA25693@broadcom.com>
On 10/27/2016 02:21 PM, Jon Mason wrote:
> On Thu, Oct 27, 2016 at 11:17:57AM +0200, Andrew Lunn wrote:
>> On Wed, Oct 26, 2016 at 03:35:58PM -0400, Jon Mason wrote:
>>> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>>> ---
>>> Documentation/devicetree/bindings/net/brcm,amac.txt | 7 +++++--
>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> index ba5ecc1..f92caee 100644
>>> --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> @@ -2,15 +2,18 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
>>> -------------------------------------------------------------
>>>
>>> Required properties:
>>> - - compatible: "brcm,amac" or "brcm,nsp-amac"
>>> + - compatible: "brcm,amac", "brcm,nsp-amac", or "brcm,ns2-amac"
>>> - reg: Address and length of the GMAC registers,
>>> Address and length of the GMAC IDM registers
>>> + Address and length of the NIC Port Manager registers (optional)
>>> - reg-names: Names of the registers. Must have both "amac_base" and
>>> - "idm_base"
>>> + "idm_base". "nicpm_base" is optional (required for NS2)
>>> - interrupts: Interrupt number
>>>
>>> Optional properties:
>>> - mac-address: See ethernet.txt file in the same directory
>>> +- brcm,enet-phy-lane-swap:
>>> + boolean; Swap the PHY lanes (needed on some SKUs of NS2)
>>
>> Maybe i'm missing something here, but the patch to the PHY swapped the
>> lanes. This seems to be a PHY property, not a MAC property. And it
>> swapped them unconditionally....
>
> It swapped them based on (from patch 1/5)
> if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810 &&
> phydev->dev_flags & PHY_BRCM_EXP_LANE_SWAP)
>
> That flag is being set in the driver based on whether the lanes need
> to be swapped (which depends on the SKU of NS2). The only SKU of NS2
> we have upstream right now has it swapped, but one that should be
> pushed out in the next few weeks will not have this flag present.
> There is no way to detect it, and having a separate compat string
> seemed overkill.
Andrew has a point thought that this is a property that is associated
with the PHY, and not with the Ethernet MAC per se, as such, you can put
it in the Ethernet PHY node, and look up the proper from
drivers/net/phy/broadcom.c, and come up with a Broadcom Ethernet PHY
binding document (sorry).
There is no need to have a specific compatible string allocated, using
the (mostly) generic Ethernet PHY binding, plus this property documented
would be good enough.
--
Florian
^ permalink raw reply
* [PATCH v7] spi: sun4i: Allow transfers larger than FIFO size
From: Maxime Ripard @ 2016-10-27 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027111419.GK25322@sirena.org.uk>
Hi Mark,
On Thu, Oct 27, 2016 at 12:14:19PM +0100, Mark Brown wrote:
> On Wed, Oct 26, 2016 at 10:55:28AM +0200, Maxime Ripard wrote:
> > On Wed, Oct 26, 2016 at 12:00:30AM -0700, Alexandru Gagniuc wrote:
>
> > > When DMA finally takes over, this fallback path is not mutually exclusive.
>
> > I definitely agree, and we had this patch in the CHIP kernel for quite
> > some time, working like a charm.
>
> > I was planning to respin it in the next few days, glad to see you took
> > care of it :)
>
> > Mark, any comments on this? For the record, it already has my Acked-by.
>
> Without knowing what the previous discussion was it's hard to comment,
> it sounds like some prior review comments are just being ignored here
> but since I'm not turning up anything with this subject line I've no
> idea what that might have been (and that's very concerning in itself
> given that this is apparently v7...).
v4 was here: https://patchwork.kernel.org/patch/3893371/
v5: https://patchwork.kernel.org/patch/5455381/
v6: https://patchwork.kernel.org/patch/6975871/
So basically, I really have no idea why, but it really seems like it
was just falling through the cracks, repeatedly (I'm not puting the
blame on anyone though, it just happened). Maybe it was just because
of the lack of comments :)
> I'm also concerned that there isn't a version of this for sun6i,
> it's going to make all the cut'n'pasting between the two drivers
> harder if we make changes in one and not the other.
I think I'll give reg_field a shot though, and try to merge the sun6i
driver into this one and see the results. If it can help your
decision.
> If the concern from the previous reviews to do with not using DMA is
> there some reason it's hard to do DMA?
I think just like Alexandru that it is orthogonal. But to really
answer, no, it's not difficult. There's just been some fundamental
disagreement on whether DMA was supposed to be optional or not that
stalled everything I guess.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161027/21a7c571/attachment.sig>
^ permalink raw reply
* [PATCH v5 0/7] Add R8A7743/SK-RZG1M board support
From: Sergei Shtylyov @ 2016-10-27 21:33 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
Here's the set of 7 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20161024-v4.9-rc2' tag. I'm adding the device tree support for
the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
seems identical to the R8A7791/Porter board. The device tree patches depend on
the R8A7743 CPG/MSSR driver series just re-posted in order to compile and work.
Already merged patches from this series won't be re-posted.
[1/7] ARM: dts: r8a7743: initial SoC device tree
[2/7] ARM: dts: r8a7743: add SYS-DMAC support
[3/7] ARM: dts: r8a7743: add [H]SCIF{A|B} support
[4/7] ARM: dts: r8a7743: add Ether support
[5/7] ARM: dts: r8a7743: add IRQC support
[6/7] ARM: dts: sk-rzg1m: initial device tree
[7/7] ARM: dts: sk-rzg1m: add Ether support
WBR, Sergei
^ permalink raw reply
* [PATCH v5 1/7] ARM: dts: r8a7743: initial SoC device tree
From: Sergei Shtylyov @ 2016-10-27 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1580369.yToZzJza1l@wasted.cogentembedded.com>
The initial R8A7743 SoC device tree including CPU0, GIC, timer, SYSC, RST,
CPG, and the required clock descriptions.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 5:
- added the RST device node, updated the patch description accordingly.
Changes in version 4:
- removed the CPU1 node, updated the patch description accordingly;
- reformatted the "interrupts" props of the GIC/timer device nodes;
- added Geert's tag.
Changes in version 3:
- changed the R8A7743 clock header #include;
- replaced the multiple clock nodes with the single CPG node, updated the
"clocks" property in the CPU0 node, updated the patch description.
Changes in version 2:
- added the IRQC and Ether clocks.
arch/arm/boot/dts/r8a7743.dtsi | 120 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 120 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -0,0 +1,120 @@
+/*
+ * Device Tree Source for the r8a7743 SoC
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/r8a7743-cpg-mssr.h>
+#include <dt-bindings/power/r8a7743-sysc.h>
+
+/ {
+ compatible = "renesas,r8a7743";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ clock-frequency = <1500000000>;
+ clocks = <&cpg CPG_CORE R8A7743_CLK_Z>;
+ power-domains = <&sysc R8A7743_PD_CA15_CPU0>;
+ next-level-cache = <&L2_CA15>;
+ };
+
+ L2_CA15: cache-controller at 0 {
+ compatible = "cache";
+ reg = <0>;
+ cache-unified;
+ cache-level = <2>;
+ power-domains = <&sysc R8A7743_PD_CA15_SCU>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller at f1001000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0 0xf1001000 0 0x1000>,
+ <0 0xf1002000 0 0x1000>,
+ <0 0xf1004000 0 0x2000>,
+ <0 0xf1006000 0 0x2000>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ cpg: clock-controller at e6150000 {
+ compatible = "renesas,r8a7743-cpg-mssr";
+ reg = <0 0xe6150000 0 0x1000>;
+ clocks = <&extal_clk>, <&usb_extal_clk>;
+ clock-names = "extal", "usb_extal";
+ #clock-cells = <2>;
+ #power-domain-cells = <0>;
+ };
+
+ sysc: system-controller at e6180000 {
+ compatible = "renesas,r8a7743-sysc";
+ reg = <0 0xe6180000 0 0x0200>;
+ #power-domain-cells = <1>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7743-rst";
+ reg = <0 0xe6160000 0 0x0200>;
+ };
+ };
+
+ /* External root clock */
+ extal_clk: extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overriden by the board. */
+ clock-frequency = <0>;
+ };
+
+ /* External USB clock - can be overridden by the board */
+ usb_extal_clk: usb_extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <48000000>;
+ };
+
+ /* External SCIF clock */
+ scif_clk: scif {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+};
^ 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