* [PATCH v6 01/14] ACPI: ARM64: IORT: minor cleanup for iort_match_node_callback()
From: Lorenzo Pieralisi @ 2017-01-03 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-2-git-send-email-hanjun.guo@linaro.org>
On Mon, Jan 02, 2017 at 09:31:32PM +0800, Hanjun Guo wrote:
> Cleanup iort_match_node_callback() a little bit to reduce
> some lines of code, aslo fix the indentation in iort_scan_node().
s/aslo/also
"Also" in a commit log is a sign a patch should be split and that's what
you should do even though I know it is tempting to merge all trivial
changes into one single patch.
Make it two patches please.
Thanks,
Lorenzo
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Majun <majun258@huawei.com>
> Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> ---
> drivers/acpi/arm64/iort.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index e0d2e6e..46e2d82 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -225,7 +225,7 @@ static struct acpi_iort_node *iort_scan_node(enum acpi_iort_node_type type,
>
> if (iort_node->type == type &&
> ACPI_SUCCESS(callback(iort_node, context)))
> - return iort_node;
> + return iort_node;
>
> iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> iort_node->length);
> @@ -253,17 +253,15 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
> void *context)
> {
> struct device *dev = context;
> - acpi_status status;
> + acpi_status status = AE_NOT_FOUND;
>
> if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT) {
> struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
> struct acpi_device *adev = to_acpi_device_node(dev->fwnode);
> struct acpi_iort_named_component *ncomp;
>
> - if (!adev) {
> - status = AE_NOT_FOUND;
> + if (!adev)
> goto out;
> - }
>
> status = acpi_get_name(adev->handle, ACPI_FULL_PATHNAME, &buf);
> if (ACPI_FAILURE(status)) {
> @@ -289,8 +287,6 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
> */
> status = pci_rc->pci_segment_number == pci_domain_nr(bus) ?
> AE_OK : AE_NOT_FOUND;
> - } else {
> - status = AE_NOT_FOUND;
> }
> out:
> return status;
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v2] watchdog: constify watchdog_info structures
From: Adam Thomson @ 2017-01-03 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482771911-13548-1-git-send-email-bhumirks@gmail.com>
On 26 December 2016 17:05, Bhumika Goyal wrote:
> Declare watchdog_info structures as const as they are only stored in the
> info field of watchdog_device structures. This field is of type const
> struct watchdog_info *, so watchdog_info structures having this property
> can be declared const too.
> diff --git a/drivers/watchdog/da9052_wdt.c b/drivers/watchdog/da9052_wdt.c
> index 2fc19a3..d86a57e 100644
> --- a/drivers/watchdog/da9052_wdt.c
> +++ b/drivers/watchdog/da9052_wdt.c
> @@ -140,7 +140,7 @@ static int da9052_wdt_ping(struct watchdog_device
> *wdt_dev)
> return ret;
> }
>
> -static struct watchdog_info da9052_wdt_info = {
> +static const struct watchdog_info da9052_wdt_info = {
> .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
> .identity = "DA9052 Watchdog",
> };
> diff --git a/drivers/watchdog/da9055_wdt.c b/drivers/watchdog/da9055_wdt.c
> index 8377c43..4f30818 100644
> --- a/drivers/watchdog/da9055_wdt.c
> +++ b/drivers/watchdog/da9055_wdt.c
> @@ -108,7 +108,7 @@ static int da9055_wdt_stop(struct watchdog_device
> *wdt_dev)
> return da9055_wdt_set_timeout(wdt_dev, 0);
> }
>
> -static struct watchdog_info da9055_wdt_info = {
> +static const struct watchdog_info da9055_wdt_info = {
> .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
> .identity = "DA9055 Watchdog",
> };
For DA9052 and DA9055:
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
^ permalink raw reply
* [PATCH v2 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Jose Abreu @ 2017-01-03 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A66012C@XAP-PVEXMBX01.xlnx.xilinx.com>
Hi Kedar,
On 02-01-2017 16:00, Appana Durga Kedareswara Rao wrote:
> Hi Jose Miguel Abreu,
>
> Thanks for the review...
>
> [snip]...
>> I just noticed there is a write to XILINX_DMA_REG_FRMSTORE which, by the
>> description in the VDMA databook, allows to modify the total number of
>> framebuffers.
>>
>> Does it correct this situation: Lets assume VDMA has 10 framebuffers in HW and
>> user only submits 5 descriptors. Then vsize will be programmed and VDMA will
>> start. The VDMA will start in fb 1, then 2, ... until 5 its all ok. But then after the fb
>> 5 the VDMA will jump to fb 6, this fb will have no address because the user only
>> submitted 5 addresses so VDMA will try to write to location 0x0 of system mem
>> (if using S2MM channel). ?
>>
>> If so then there is no race condition, but the HW image that I have does not
>> have this register enabled so I was getting this result (memory corruption
>> because not all framebuffers had addresses set).
> Thanks for the explanation.
> Agree the issue that you mentioned won't come when XILINX_DMA_REG_FRMSTORE
> (C_ENABLE_DEBUG_INFO_5 and C_ENABLE_DEBUG_INFO_13) Register is enabled in the IP.
> But this register won't get enabled with the default IP configuration (C_ENABLE_DEBUG_INFO_5 and C_ENABLE_DEBUG_INFO_13).
>
> When user is not enabled XILINX_DMA_REG_FRMSTORE in the h/w and submits frames less than h/w capable.
> The solution that I am thinking is to throw an error in the driver saying that either enable the
> num frame store feature in the IP or submit the frames up to h/w capable what do you think???
Sounds fine by me.
Best regards,
Jose Miguel Abreu
>
> Regards,
> Kedar.
>
>> Best regards,
>> Jose Miguel Abreu
>>
>>> Regards,
>>> Kedar.
>>>
>>>> Best regards,
>>>> Jose Miguel Abreu
>>>>
^ permalink raw reply
* [RFC PATCH] iommu/arm-smmu: Add global SMR masking property
From: Will Deacon @ 2017-01-03 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221032921.hdcnyiq6m224ejlv@rob-hp-laptop>
On Tue, Dec 20, 2016 at 09:29:21PM -0600, Rob Herring wrote:
> On Fri, Dec 16, 2016 at 01:19:29PM +0000, Robin Murphy wrote:
> > The current SMR masking support using a 2-cell iommu-specifier is
> > primarily intended to handle individual masters with large and/or
> > complex Stream ID assignments; it quickly gets a bit clunky in other SMR
> > use-cases where we just want to consistently mask out the same part of
> > every Stream ID (e.g. for MMU-500 configurations where the appended TBU
> > number gets in the way unnecessarily). Let's add a new property to allow
> > a single global mask value to better fit the latter situation.
> >
> > CC: Stuart Yoder <stuart.yoder@nxp.com>
> > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > ---
> >
> > Compile-tested only...
> >
> > Documentation/devicetree/bindings/iommu/arm,smmu.txt | 8 ++++++++
> > drivers/iommu/arm-smmu.c | 4 +++-
> > 2 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > index e862d1485205..98f5cbe5fdb4 100644
> > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > @@ -60,6 +60,14 @@ conditions.
> > aliases of secure registers have to be used during
> > SMMU configuration.
> >
> > +- stream-match-mask : Specifies a fixed SMR mask value to combine with
>
> Needs a vendor prefix.
Why does this need a vendor prefix? I'm not fussed either way, but since
the stream-match-mask is an optional architectural concept and not specific
to an implementation, it seems strange to me that it would need a prefix
whereas something like #global-interrupts does not.
> > + the Stream ID value from every iommu-specifier. This
> > + may be used instead of an "#iommu-cells" value of 2
> > + when there is no need for per-master SMR masks, but
> > + it is still desired to mask some portion of every
> > + Stream ID (e.g. for certain MMU-500 configurations
> > + given globally unique external IDs).
Robin -- it might be worth a sentence here saying that the property is
ignored if stream matching isn't supported by the hardware.
Will
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx6qdl-nitrogen6_som2: fix sgtl5000 pinctrl init
From: Gary Bisson @ 2017-01-03 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103112247.4563-3-gary.bisson@boundarydevices.com>
Hi Shawn,
On Tue, Jan 03, 2017 at 12:22:47PM +0100, Gary Bisson wrote:
> Since the codec is probed first, the pinctrl node should be
> under the codec node.
>
> The codec init was working for this board since U-Boot was
> already setting GPIO_0 as CLKO1 but better fix it anyway.
>
> Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Fixes: 3faa1bb2e89c ("ARM: dts: imx: add Boundary Devices Nitrogen6_SOM2 support")
Thanks,
Gary
^ permalink raw reply
* [PATCH] input: tm2-touchkey: fix odd_ptr_err.cocci warnings
From: Julia Lawall @ 2017-01-03 13:39 UTC (permalink / raw)
To: linux-arm-kernel
PTR_ERR should access the value just tested by IS_ERR
Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
CC: Jaechul Lee <jcsing.lee@samsung.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
I have only looked at the extract of code that is shown here. It could be
the test that is wrong.
The code comes from:
url:
https://github.com/0day-ci/linux/commits/Jaechul-Lee/Add-touch-key-driver-su
pport-for-TM2/20170103-183357
:::::: branch date: 2 hours ago
:::::: commit date: 2 hours ago
tm2-touchkey.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/input/keyboard/tm2-touchkey.c
+++ b/drivers/input/keyboard/tm2-touchkey.c
@@ -196,7 +196,7 @@ static int tm2_touchkey_probe(struct i2c
devm_regulator_get(&client->dev, "vdd");
if (IS_ERR(samsung_touchkey->regulator_vdd)) {
dev_err(&client->dev, "Failed to get vdd regulator\n");
- return PTR_ERR(samsung_touchkey->regulator_vcc);
+ return PTR_ERR(samsung_touchkey->regulator_vdd);
}
/* power */
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6qdl-nitrogen6_max: fix sgtl5000 pinctrl init
From: Shawn Guo @ 2017-01-03 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103115530.vngqbev7nsavgtdc@t450s.lan>
On Tue, Jan 03, 2017 at 12:55:49PM +0100, Gary Bisson wrote:
> Hi Shawn,
>
> On Tue, Jan 03, 2017 at 07:43:17PM +0800, Shawn Guo wrote:
> > On Tue, Jan 03, 2017 at 12:22:46PM +0100, Gary Bisson wrote:
> > > This patch fixes the following error:
> > > sgtl5000 0-000a: Error reading chip id -6
> > > imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
> > > imx-sgtl5000 sound: snd_soc_register_card failed (-517)
> > >
> > > The problem was that the pinctrl group was linked to the sound driver
> > > instead of the codec node. Since the codec is probed first, the sys_mclk
> > > was missing and it would therefore fail to initialize.
> > >
> > > Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
> >
> > Should we have it go as a fix for v4.10-rc cycles? In that case, please
> > add a Fixes: tag. Also, do we need to apply it for stable kernel?
>
> Sure it'd be great if it could be in v4.10.
> Fixes: b32e700256bc ("ARM: dts: imx: add Boundary Devices Nitrogen6_Max board")
>
> As for stable kernel, I guess it wouldn't hurt but it's not mandatory in
> my opinion.
I wouldn't bother stable kernel then.
>
> Do you want me to re-send with the Fixes line?
No. I can add the Fixes tag.
> What about the SOM2
> patch, should it include a Fixes line although it works thanks to
> U-Boot?
Yes, please give me the Fixes tag, and I will send both patches for
v4.10 inclusion.
Shawn
^ permalink raw reply
* [PATCH 3/5] arm64: dts: sun50i: add MMC nodes
From: Chen-Yu Tsai @ 2017-01-03 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d4c2233c-95aa-4d72-1501-9ecb62f6cd82@arm.com>
On Tue, Jan 3, 2017 at 6:48 PM, Andr? Przywara <andre.przywara@arm.com> wrote:
> On 03/01/17 02:52, Chen-Yu Tsai wrote:
>
> Hi,
>
>> On Tue, Jan 3, 2017 at 7:03 AM, Andre Przywara <andre.przywara@arm.com> wrote:
>>
>> A commit message explaining the mmc controllers would be nice.
>
> OK.
>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 67 +++++++++++++++++++++++++++
>>> 1 file changed, 67 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> index e0dcab8..c680566 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> @@ -150,6 +150,32 @@
>>> pins = "PB8", "PB9";
>>> function = "uart0";
>>> };
>>> +
>>> + mmc0_pins: mmc0 at 0 {
>>> + pins = "PF0", "PF1", "PF2", "PF3", "PF4", "PF5";
>>> + function = "mmc0";
>>> + drive-strength = <30>;
>>> + };
>>> +
>>> + mmc0_default_cd_pin: mmc0_cd_pin at 0 {
>>> + pins = "PF6";
>>> + function = "gpio_in";
>>> + bias-pull-up;
>>> + };
>>
>> We are starting to drop pinmux nodes for gpio usage.
>
> And replacing them with what?
> Or do you mean they go in the individual board .dts files?
> In this case I believe having a default pin defined here would help to
> define it in every .dts.
Nope. I meant dropping them. Pinmux and gpio are orthogonal. One should not
need to specify a gpio pinmux to use it as a gpio. We added them because in
the past nothing was preventing someone from claiming an already muxed pin
as a gpio. On some platforms this is fine. For sunxi, this breaks the system,
as the gpio functions are muxed in.
The idea moving forward is that these cases should be guarded in the driver.
Of course we would have to deal with existing dtbs, but lets not add any more.
>>> +
>>> + mmc1_pins: mmc1 at 0 {
>>> + pins = "PG0", "PG1", "PG2", "PG3", "PG4", "PG5";
>>> + function = "mmc1";
>>> + drive-strength = <30>;
>>> + };
>>> +
>>> + mmc2_pins: mmc2 at 0 {
>>> + pins = "PC1", "PC5", "PC6", "PC8", "PC9",
>>> + "PC10", "PC11", "PC12", "PC13", "PC14",
>>> + "PC15", "PC16";
>>> + function = "mmc2";
>>> + drive-strength = <30>;
>>> + };
>>
>> Moreover I think you should split out the pinmux nodes to a separate patch.
>
> I can surely do, just wondering what's the rationale is behind that?
More or less the "do one thing in one patch" rationale. Of course you can
claim these are the defaults used in the reference design and pretty much
every board out there. Then it makes sense to do them together. :)
>
>>
>>> };
>>>
>>> uart0: serial at 1c28000 {
>>> @@ -240,6 +266,47 @@
>>> #size-cells = <0>;
>>> };
>>>
>>> + mmc0: mmc at 1c0f000 {
>>> + compatible = "allwinner,sun50i-a64-mmc",
>>> + "allwinner,sun5i-a13-mmc";
>>
>> Given that sun5i doesn't support mmc delay timings, and the A64 has
>> calibration and delay timings, I wouldn't call them compatible.
>>
>> Or are you claiming that for the A64 has a delay of 0 for the
>> currently supported speeds, so the calibration doesn't really
>> matter? If so this should be mentioned in the commit message.
>
> Yes, that's my observation: Driving it with sun5-a13-mmc just works.
> This sun5i driver version does not (and will never) support higher
> transfer modes anyway, so for that subset they are compatible. This
> opens up the door to other operating systems not having a particular
> driver for the A64, for instance, also older Linux kernels.
> I know that sunxi doesn't use this compatible feature much, but IMHO we
> should really start thinking about the DT not just being Linux specific
> - or even being specific to a certain Linux version. And this case here
> is a good example: An A13 MMC driver can drive this device - if there is
> no better driver (an A64 one) available.
Cool. Please put this in the commit log. :)
>
>>
>>> + reg = <0x01c0f000 0x1000>;
>>> + clocks = <&ccu 31>, <&ccu 75>;
>>
>> The clock / reset index macros are in the tree now.
>> Please switch to them.
>
> The include file is in the tree, but it isn't used in the current HEAD
> (as in #included and the actual macros being used in the .dtsi).
> So I was wondering if there is a patch pending for that?
Not yet I think. Perhaps Maxime will do one once he gets back from vacation?
Regards
ChenYu
>
> Cheers,
> Andre
>
>>> + clock-names = "ahb", "mmc";
>>> + resets = <&ccu 8>;
>>> + reset-names = "ahb";
>>> + interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
>>> + status = "disabled";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + };
>>> +
>>> + mmc1: mmc at 1c10000 {
>>> + compatible = "allwinner,sun50i-a64-mmc",
>>> + "allwinner,sun5i-a13-mmc";
>>> + reg = <0x01c10000 0x1000>;
>>> + clocks = <&ccu 32>, <&ccu 76>;
>>> + clock-names = "ahb", "mmc";
>>> + resets = <&ccu 9>;
>>> + reset-names = "ahb";
>>> + interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
>>> + status = "disabled";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + };
>>> +
>>> + mmc2: mmc at 1c11000 {
>>> + compatible = "allwinner,sun50i-a64-emmc";
>>> + reg = <0x01c11000 0x1000>;
>>> + clocks = <&ccu 33>, <&ccu 77>;
>>> + clock-names = "ahb", "mmc";
>>> + resets = <&ccu 10>;
>>> + reset-names = "ahb";
>>> + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
>>> + status = "disabled";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + };
>>> +
>>> gic: interrupt-controller at 1c81000 {
>>> compatible = "arm,gic-400";
>>> reg = <0x01c81000 0x1000>,
>>> --
>>> 2.8.2
>>>
>
^ permalink raw reply
* [PATCH v5 0/6] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Ding Tianhong @ 2017-01-03 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <586B7709.1080600@huawei.com>
On 2017/1/3 18:03, Hanjun Guo wrote:
> Hi Ding,
>
> On 2016/12/23 15:04, Ding Tianhong wrote:
>> Erratum Hisilicon-161601 says that the ARM generic timer counter "has the
>> potential to contain an erroneous value when the timer value changes".
>> Accesses to TVAL (both read and write) are also affected due to the implicit counter
>> read. Accesses to CVAL are not affected.
>>
>> The workaround is to reread the system count registers until the value of the second
>> read is larger than the first one by less than 32, the system counter can be guaranteed
>> not to return wrong value twice by back-to-back read and the error value is always larger
>> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
>>
>> v2: Introducing a new generic erratum handling mechanism for fsl,a008585 and hisilicon,161601.
>> Significant rework based on feedback, including seperate the fsl erratum a008585
>> to another patch, update the erratum name and remove unwanted code.
>>
>> v3: Introducing the erratum_workaround_set_sne generic function for fsl erratum a008585
>> and make the #define __fsl_a008585_read_reg to be private to the .c file instead of
>> being globally visible. After discussion with Marc and Will, a consensus decision was
>> made to remove the commandline parameter for enabling fsl,erratum-a008585 erratum,
>> and make some generic name more specific, export timer_unstable_counter_workaround
>> for module access.
>>
>> Significant rework based on feedback, including fix some alignment problem, make the
>> #define __hisi_161601_read_reg to be private to the .c file instead of being globally
>> visible, add more accurate annotation and modify a bit of logical format to enable
>> arch_timer_read_ool_enabled, remove the kernel commandline parameter
>> clocksource.arm_arch_timer.hisilicon-161601.
>>
>> Introduce a generic aquick framework for erratum in ACPI mode.
>>
>> v4: rename the quirk handler parameter to make it more generic, and
>> avoid break loop when handling the quirk becasue it need to
>> support multi quirks handler.
>>
>> update some data structures for acpi mode.
>>
>> v5: Adapt the new kernel-parameters.txt for latest kernel version.
>> Set the retries of reread system counter to 50, because it is possible
>> that some interrupts may lead to more than twice read errors and break the loop,
>> it will trigger the warning, so we set the number of retries far beyond the number of
>> iterations the loop has been observed to take.
>>
>> Ding Tianhong (4):
>> arm64: arch_timer: Add device tree binding for hisilicon-161601
>> erratum
>> arm64: arch_timer: Introduce a generic erratum handing mechanism for
>> fsl-a008585
>> arm64: arch_timer: Work around Erratum Hisilicon-161601
>> arm64: arch timer: Add timer erratum property for Hip05-d02 and
>> Hip06-d03
>>
>> Hanjun Guo (2):
>> arm64: arch_timer: apci: Introduce a generic aquirk framework for
>> erratum
>> arm64: arch_timer: acpi: add hisi timer errata data
>
> Since the ACPI code is conflict with Fuwei's GTDT patch set, let's split this patch
> set into two parts, one is the DT based code, and the other is the ACPI part,
> I will rebase ACPI code on top of Fuwei's patch set so please go upstream first.
>
Hi Hanjuno<\x1a
OK, I will remove the last 2 patch and resend a new version only support DT.
> Thanks
> Hanjun
>
>
> .
>
^ permalink raw reply
* [PATCH] crypto: mediatek: don't return garbage err on successful return
From: Colin King @ 2017-01-03 13:21 UTC (permalink / raw)
To: linux-arm-kernel
From: Colin Ian King <colin.king@canonical.com>
In the case where keylen <= bs mtk_sha_setkey returns an uninitialized
return value in err. Fix this by returning 0 instead of err.
Issue detected by static analysis with cppcheck.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/crypto/mediatek/mtk-sha.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/mediatek/mtk-sha.c b/drivers/crypto/mediatek/mtk-sha.c
index 8951363..8e1b440 100644
--- a/drivers/crypto/mediatek/mtk-sha.c
+++ b/drivers/crypto/mediatek/mtk-sha.c
@@ -878,7 +878,7 @@ static int mtk_sha_setkey(struct crypto_ahash *tfm,
bctx->opad[i] ^= 0x5c;
}
- return err;
+ return 0;
}
static int mtk_sha_export(struct ahash_request *req, void *out)
--
2.10.2
^ permalink raw reply related
* [RESEND PATCH 0/6] apalis-tk1: updates for v1.1 hw
From: Marcel Ziswiler @ 2017-01-03 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124010456.24604-1-marcel@ziswiler.com>
On Thu, 2016-11-24 at 02:04 +0100, marcel at ziswiler.com wrote:
> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
>
> This series updates the device tree for the upcoming V1.1 HW samples.
> All changes are purely opportunistic meaning they fix stuff which on
> older HW was anyway broken so there should be no backwards
> compatibility issues.
>
>
> Marcel Ziswiler (6):
> ? apalis-tk1: remove spurious new lines
> ? apalis-tk1: temp alert pull-up
> ? apalis-tk1: optional displayport hot-plug detect
> ? apalis-tk1: adjust pin muxing for v1.1 hw
> ? apalis-tk1: working sd card detect on v1.1 hw
> ? apalis-tk1: update compatibility comment
>
> ?arch/arm/boot/dts/tegra124-apalis-eval.dts | 11 +----
> ?arch/arm/boot/dts/tegra124-apalis.dtsi?????| 73 +++++++++++---------
> ----------
> ?2 files changed, 29 insertions(+), 55 deletions(-)
Ping.
^ permalink raw reply
* [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR
From: Arnd Bergmann @ 2017-01-03 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALCETrV_qejd-Ozqo4vTqz=LuukMUPeQ7EVUQbfTxs_xNbO3oQ@mail.gmail.com>
On Monday, January 2, 2017 10:08:28 PM CET Andy Lutomirski wrote:
>
> > This seems to nicely address the same problem on arm64, which has
> > run into the same issue due to the various page table formats
> > that can currently be chosen at compile time.
>
> On further reflection, I think this has very little to do with paging
> formats except insofar as paging formats make us notice the problem.
> The issue is that user code wants to be able to assume an upper limit
> on an address, and it gets an upper limit right now that depends on
> architecture due to paging formats. But someone really might want to
> write a *portable* 64-bit program that allocates memory with the high
> 16 bits clear. So let's add such a mechanism directly.
>
> As a thought experiment, what if x86_64 simply never allocated "high"
> (above 2^47-1) addresses unless a new mmap-with-explicit-limit syscall
> were used? Old glibc would continue working. Old VMs would work.
> New programs that want to use ginormous mappings would have to use the
> new syscall. This would be totally stateless and would have no issues
> with CRIU.
I can see this working well for the 47-bit addressing default, but
what about applications that actually rely on 39-bit addressing
(I'd have to double-check, but I think this was the limit that
people were most interested in for arm64)?
39 bits seems a little small to make that the default for everyone
who doesn't pass the extra flag. Having to pass another flag to
limit the addresses introduces other problems (e.g. mmap from
library call that doesn't pass that flag).
> If necessary, we could also have a prctl that changes a
> "personality-like" limit that is in effect when the old mmap was used.
> I say "personality-like" because it would reset under exactly the same
> conditions that personality resets itself.
For "personality-like", it would still have to interact
with the existing PER_LINUX32 and PER_LINUX32_3GB flags that
do the exact same thing, so actually using personality might
be better.
We still have a few bits in the personality arguments, and
we could combine them with the existing ADDR_LIMIT_3GB
and ADDR_LIMIT_32BIT flags that are mutually exclusive by
definition, such as
ADDR_LIMIT_32BIT = 0x0800000, /* existing */
ADDR_LIMIT_3GB = 0x8000000, /* existing */
ADDR_LIMIT_39BIT = 0x0010000, /* next free bit */
ADDR_LIMIT_42BIT = 0x8010000,
ADDR_LIMIT_47BIT = 0x0810000,
ADDR_LIMIT_48BIT = 0x8810000,
This would probably take only one or two personality bits for the
limits that are interesting in practice.
Arnd
^ permalink raw reply
* [PATCH 4/4] arm64: dts: exynos: Add tm2 touchkey node
From: Javier Martinez Canillas @ 2017-01-03 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483430237-26823-5-git-send-email-jcsing.lee@samsung.com>
Hello Jaechul,
On 01/03/2017 04:57 AM, Jaechul Lee wrote:
> Add DT node support for TM2 touchkey device.
>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 887a1f1..ef7d21c 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -18,3 +18,15 @@
> compatible = "samsung,tm2e", "samsung,exynos5433";
> };
>
> +&hsi2c_9 {
> + status = "okay";
> +
> + touchkey at 20 {
> + compatible = "samsung,tm2-touchkey";
> + reg = <0x20>;
> + interrupt-parent = <&gpa3>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + vcc-supply = <&ldo32_reg>;
> + vdd-supply = <&ldo33_reg>;
> + };
> +};
>
If you re-spin with the changes suggested by Chanwoo instead
of the commont .dtsi, feel free to add:
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v3 2/3] DT: bingdings: power: reset: add linkstation-reset doc
From: Andrew Lunn @ 2017-01-03 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <519e07d0-9b73-4445-ec5e-7ea2cbc1b814@gmail.com>
> > +
> > +Required Properties:
> > +- compatible: Should be "linkstation,power-off"
> > +- reg: Address and length of the register set for UART1
>
> Humm, should we instead have a phandle to the uart1 node?
Probably. Again, this is to do with copying the QNAP driver. I was
young, new to device tree, and i just did a logical conversion of the
existing code, and did not at the time understand phandles, etc.
Andrew
^ permalink raw reply
* [PATCH 2/4] input: tm2-touchkey: Add touchkey driver support for TM2
From: Javier Martinez Canillas @ 2017-01-03 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483430237-26823-3-git-send-email-jcsing.lee@samsung.com>
Hello Jaechul,
On 01/03/2017 04:57 AM, Jaechul Lee wrote:
> This patch adds support for the TM2 touch key and led
> functionlity.
>
s/functionlity/functionality
> The driver interfaces with userspace through an input device and
> reports KEY_PHONE and KEY_BACK event types. LED brightness can be
> controlled by "/sys/class/leds/tm2-touchkey/brightness".
>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> ---
> drivers/input/keyboard/Kconfig | 11 ++
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/tm2-touchkey.c | 326 ++++++++++++++++++++++++++++++++++
> 3 files changed, 338 insertions(+)
> create mode 100644 drivers/input/keyboard/tm2-touchkey.c
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index cbd75cf..72c0ba1 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -666,6 +666,17 @@ config KEYBOARD_TC3589X
> To compile this driver as a module, choose M here: the
> module will be called tc3589x-keypad.
>
> +config KEYBOARD_TM2_TOUCHKEY
> + tristate "tm2-touchkey support"
> + depends on I2C
> + help
> + Say Y here to enable the tm2-touchkey.
> + touchkey driver for tm2. This driver can enable
> + the interrupt and make input events and control led brightness.
> +
> + To compile this driver as a module, choose M here.
> + module will be called tm2-touchkey
> +
> config KEYBOARD_TWL4030
> tristate "TI TWL4030/TWL5030/TPS659x0 keypad support"
> depends on TWL4030_CORE
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index d9f4cfc..7d9acff 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_KEYBOARD_SUN4I_LRADC) += sun4i-lradc-keys.o
> obj-$(CONFIG_KEYBOARD_SUNKBD) += sunkbd.o
> obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
> obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
> +obj-$(CONFIG_KEYBOARD_TM2_TOUCHKEY) += tm2-touchkey.o
> obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
> obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
> obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
> diff --git a/drivers/input/keyboard/tm2-touchkey.c b/drivers/input/keyboard/tm2-touchkey.c
> new file mode 100644
> index 0000000..d9575d8
> --- /dev/null
> +++ b/drivers/input/keyboard/tm2-touchkey.c
> @@ -0,0 +1,326 @@
> +/*
> + * Driver for keys on GPIO lines capable of generating interrupts.
> + *
> + * Copyright 2005 Phil Blundell
> + * Copyright 2016 Samsung Electronics Co., Ltd.
> + *
> + * Author: Beomho Seo <beomho.seo@samsung.com>
> + * Author: Jaechul Lee <jcsing.lee@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/i2c.h>
> +#include <linux/input.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/leds.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pm.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/workqueue.h>
> +
> +#define TM2_TOUCHKEY_DEV_NAME "tm2-touchkey"
> +#define TM2_TOUCHKEY_KEYCODE_REG 0x03
> +#define TM2_TOUCHKEY_BASE_REG 0x00
> +#define TM2_TOUCHKEY_CMD_LED_ON 0x10
> +#define TM2_TOUCHKEY_CMD_LED_OFF 0x20
> +#define TM2_TOUCHKEY_BIT_PRESS_EV BIT(3)
> +#define TM2_TOUCHKEY_BIT_KEYCODE GENMASK(2, 0)
> +#define TM2_TOUCHKEY_LED_VOLTAGE_MIN 2500000
> +#define TM2_TOUCHKEY_LED_VOLTAGE_MAX 3300000
> +
> +enum {
> + TM2_TOUCHKEY_KEY_MENU = 0x1,
> + TM2_TOUCHKEY_KEY_BACK,
> +};
> +
> +#define tm2_touchkey_power_enable(x) __tm2_touchkey_power_onoff(x, 1)
> +#define tm2_touchkey_power_disable(x) __tm2_touchkey_power_onoff(x, 0)
> +
> +struct tm2_touchkey_data {
> + struct i2c_client *client;
> + struct input_dev *input_dev;
> + struct led_classdev led_dev;
> +
> + u8 keycode_type;
> + u8 pressed;
> + struct work_struct irq_work;
> +
> + bool power_onoff;
> + struct regulator *regulator_vcc; /* 1.8V */
> + struct regulator *regulator_vdd; /* 3.3V */
> +};
> +
> +static void tm2_touchkey_led_brightness_set(struct led_classdev *led_dev,
> + enum led_brightness brightness)
> +{
> + struct tm2_touchkey_data *samsung_touchkey =
> + container_of(led_dev, struct tm2_touchkey_data, led_dev);
> + u32 volt;
> + u8 data;
> +
> + if (brightness == LED_OFF) {
> + volt = TM2_TOUCHKEY_LED_VOLTAGE_MIN;
> + data = TM2_TOUCHKEY_CMD_LED_OFF;
> + } else {
> + volt = TM2_TOUCHKEY_LED_VOLTAGE_MAX;
> + data = TM2_TOUCHKEY_CMD_LED_ON;
> + }
> +
> + regulator_set_voltage(samsung_touchkey->regulator_vdd, volt, volt);
> + i2c_smbus_write_byte_data(samsung_touchkey->client,
> + TM2_TOUCHKEY_BASE_REG, data);
> +}
> +
> +static int __tm2_touchkey_power_onoff(struct tm2_touchkey_data
> + *samsung_touchkey, bool onoff)
> +{
> + int ret = 0;
> +
> + if (samsung_touchkey->power_onoff == onoff)
> + return ret;
> +
> + if (onoff) {
> + ret = regulator_enable(samsung_touchkey->regulator_vcc);
> + if (ret)
> + return ret;
> +
> + ret = regulator_enable(samsung_touchkey->regulator_vdd);
> + if (ret) {
> + regulator_disable(samsung_touchkey->regulator_vcc);
> + return ret;
> + }
I would add a comment about the sleep here.
> + msleep(150);
> + } else {
> + int err;
> +
> + err = regulator_disable(samsung_touchkey->regulator_vcc);
> + if (err)
> + ret = err;
> +
> + err = regulator_disable(samsung_touchkey->regulator_vdd);
> + if (err && !ret)
> + ret = err;
> + }
> + samsung_touchkey->power_onoff = onoff;
> +
> + return ret;
> +}
> +
> +static void tm2_touchkey_irq_work(struct work_struct *irq_work)
> +{
> + struct tm2_touchkey_data *samsung_touchkey =
> + container_of(irq_work, struct tm2_touchkey_data, irq_work);
> +
> + if (!samsung_touchkey->pressed) {
> + input_report_key(samsung_touchkey->input_dev, KEY_PHONE, 0);
> + input_report_key(samsung_touchkey->input_dev, KEY_BACK, 0);
> + } else {
> + if (samsung_touchkey->keycode_type == TM2_TOUCHKEY_KEY_MENU)
> + input_report_key(samsung_touchkey->input_dev,
> + KEY_PHONE, 1);
> + else
> + input_report_key(samsung_touchkey->input_dev,
> + KEY_BACK, 1);
> + }
> + input_sync(samsung_touchkey->input_dev);
> +}
> +
> +static irqreturn_t tm2_touchkey_irq_handler(int irq, void *devid)
> +{
> + struct tm2_touchkey_data *samsung_touchkey = devid;
> + u32 data;
> +
> + data = i2c_smbus_read_byte_data(samsung_touchkey->client,
> + TM2_TOUCHKEY_KEYCODE_REG);
> +
> + if (data < 0) {
> + dev_err(&samsung_touchkey->client->dev, "Failed to read i2c data\n");
> + return IRQ_HANDLED;
> + }
> +
> + samsung_touchkey->keycode_type = data & TM2_TOUCHKEY_BIT_KEYCODE;
> + samsung_touchkey->pressed = !(data & TM2_TOUCHKEY_BIT_PRESS_EV);
> +
> + if (samsung_touchkey->keycode_type != TM2_TOUCHKEY_KEY_MENU &&
> + samsung_touchkey->keycode_type != TM2_TOUCHKEY_KEY_BACK)
Shouldn't at least a debug message be printed here so the user can
know that an error occurred and a correct keycode was not received?
> + return IRQ_HANDLED;
> +
> + schedule_work(&samsung_touchkey->irq_work);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int tm2_touchkey_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct tm2_touchkey_data *samsung_touchkey;
> + int ret;
> +
> + ret = i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_BYTE |
> + I2C_FUNC_SMBUS_BYTE_DATA);
> + if (!ret) {
> + dev_err(&client->dev, "No I2C functionality found\n");
> + return -ENODEV;
> + }
> +
> + samsung_touchkey = devm_kzalloc(&client->dev,
> + sizeof(struct tm2_touchkey_data), GFP_KERNEL);
> +
> + if (!samsung_touchkey) {
> + dev_err(&client->dev, "Failed to allocate memory.\n");
> + return -ENOMEM;
> + }
> +
> + samsung_touchkey->client = client;
> + i2c_set_clientdata(client, samsung_touchkey);
> + INIT_WORK(&samsung_touchkey->irq_work, tm2_touchkey_irq_work);
> +
> + /* regulator */
> + samsung_touchkey->regulator_vcc =
> + devm_regulator_get(&client->dev, "vcc");
> + if (IS_ERR(samsung_touchkey->regulator_vcc)) {
> + dev_err(&client->dev, "Failed to get vcc regulator\n");
> + return PTR_ERR(samsung_touchkey->regulator_vcc);
> + }
> +
> + samsung_touchkey->regulator_vdd =
> + devm_regulator_get(&client->dev, "vdd");
> + if (IS_ERR(samsung_touchkey->regulator_vdd)) {
> + dev_err(&client->dev, "Failed to get vdd regulator\n");
> + return PTR_ERR(samsung_touchkey->regulator_vcc);
> + }
> +
> + /* power */
> + ret = tm2_touchkey_power_enable(samsung_touchkey);
> + if (ret) {
> + dev_err(&client->dev, "Failed to enable power\n");
> + return ret;
> + }
> +
> + /* irq */
> + ret = devm_request_threaded_irq(&client->dev,
> + client->irq, NULL,
> + tm2_touchkey_irq_handler,
> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> + TM2_TOUCHKEY_DEV_NAME,
> + samsung_touchkey);
> + if (ret) {
> + dev_err(&client->dev, "Failed to request threaded irq\n");
> + return ret;
> + }
> +
> + /* input device */
> + samsung_touchkey->input_dev = devm_input_allocate_device(&client->dev);
> + if (!samsung_touchkey->input_dev) {
> + dev_err(&client->dev, "Failed to alloc input device.\n");
> + return -ENOMEM;
> + }
> + samsung_touchkey->input_dev->name = TM2_TOUCHKEY_DEV_NAME;
> + samsung_touchkey->input_dev->id.bustype = BUS_I2C;
> + samsung_touchkey->input_dev->dev.parent = &client->dev;
> +
> + set_bit(EV_KEY, samsung_touchkey->input_dev->evbit);
> + set_bit(KEY_PHONE, samsung_touchkey->input_dev->keybit);
> + set_bit(KEY_BACK, samsung_touchkey->input_dev->keybit);
> + input_set_drvdata(samsung_touchkey->input_dev, samsung_touchkey);
> +
> + ret = input_register_device(samsung_touchkey->input_dev);
> + if (ret) {
> + dev_err(&client->dev, "Failed to register input device.\n");
> + return ret;
> + }
> +
> + /* led device */
> + samsung_touchkey->led_dev.name = TM2_TOUCHKEY_DEV_NAME;
> + samsung_touchkey->led_dev.brightness = LED_FULL;
> + samsung_touchkey->led_dev.max_brightness = LED_FULL;
> + samsung_touchkey->led_dev.brightness_set =
> + tm2_touchkey_led_brightness_set;
> +
> + ret = devm_led_classdev_register(&client->dev,
> + &samsung_touchkey->led_dev);
> + if (ret < 0) {
> + dev_err(&client->dev, "Failed to register touchkey led\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void tm2_touchkey_shutdown(struct i2c_client *client)
> +{
> + struct tm2_touchkey_data *samsung_touchkey =
> + i2c_get_clientdata(client);
> + int ret;
> +
> + disable_irq(client->irq);
> + ret = tm2_touchkey_power_disable(samsung_touchkey);
> + if (ret)
> + dev_err(&client->dev, "Failed to disable power\n");
> +}
> +
> +static int tm2_touchkey_suspend(struct device *dev)
> +{
> + struct tm2_touchkey_data *samsung_touchkey = dev_get_drvdata(dev);
> + int ret;
> +
> + disable_irq(samsung_touchkey->client->irq);
> + ret = tm2_touchkey_power_disable(samsung_touchkey);
> + if (ret)
> + dev_err(dev, "Failed to disable power\n");
> +
> + return ret;
> +}
These two functions are basically the same, can you factor it out?
> +
> +static int tm2_touchkey_resume(struct device *dev)
> +{
> + struct tm2_touchkey_data *samsung_touchkey = dev_get_drvdata(dev);
> + int ret;
> +
> + enable_irq(samsung_touchkey->client->irq);
> + ret = tm2_touchkey_power_enable(samsung_touchkey);
> + if (ret)
> + dev_err(dev, "Failed to enable power\n");
> +
> + return ret;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(tm2_touchkey_pm_ops, tm2_touchkey_suspend,
> + tm2_touchkey_resume);
> +
> +static const struct i2c_device_id tm2_touchkey_id_table[] = {
> + {TM2_TOUCHKEY_DEV_NAME, 0},
> + {},
> +};
> +
You need a MODULE_DEVICE_TABLE(i2c, tm2_touchkey_id_table) here so the
module can be autoloaded when the device is registered.
> +static const struct of_device_id tm2_touchkey_of_match[] = {
> + {.compatible = "samsung,tm2-touchkey",},
> + {},
> +};
> +
Here a MODULE_DEVICE_TABLE(of, tm2_touchkey_of_match) is not strictly
needed since the I2C core always reports MODALIAS of the form i2c:<dev>
but still is good to have so the I2C core can be fixed at some point.
> +static struct i2c_driver tm2_touchkey_driver = {
> + .driver = {
> + .name = TM2_TOUCHKEY_DEV_NAME,
> + .pm = &tm2_touchkey_pm_ops,
> + .of_match_table = of_match_ptr(tm2_touchkey_of_match),
> + },
> + .probe = tm2_touchkey_probe,
> + .shutdown = tm2_touchkey_shutdown,
> + .id_table = tm2_touchkey_id_table,
> +};
> +
> +module_i2c_driver(tm2_touchkey_driver);
> +
> +MODULE_AUTHOR("Beomho Seo <beomho.seo@samsung.com>");
> +MODULE_AUTHOR("Jaechul Lee <jcsing.lee@samsung.com>");
> +MODULE_DESCRIPTION("Samsung touchkey driver");
> +MODULE_LICENSE("GPL v2");
>
The rest looks good to me, so after the changes I suggested:
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v3 1/3] power: reset: add linkstation-reset driver
From: Andrew Lunn @ 2017-01-03 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fff132e9-a178-6948-676e-6a4d24b6c4d6@gmail.com>
> > +
> > + /* Check that nothing else has already setup a handler */
> > + if (pm_power_off) {
> > + lookup_symbol_name((ulong)pm_power_off, symname);
> > + dev_err(&pdev->dev,
> > + "pm_power_off already claimed %p %s",
> > + pm_power_off, symname);
> > + return -EBUSY;
> > + }
> > + pm_power_off = linkstation_reset;
>
> That seems a bit complicated, why not just assume that there will be
> either this driver used, or not at all?
That is probably my fault. This is a copy from code i wrote many years
ago for the QNAP. I guess at the time i was battling with two
different pm_power_off handlers, so put in this code.
> Also, you are supposed to register a reboot notifier to which you can
> pass private context:
At the time i wrote the QNAP code, this did not exist. So maybe my
code is no longer a good example to copy.
Andrew
^ permalink raw reply
* [PATCH v6 6/8] IIO: add STM32 timer trigger driver
From: Benjamin Gaignard @ 2017-01-03 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks6jshX-rEsi7Qfo-65awzWcHsEMVBjm-baYy979V9187Q@mail.gmail.com>
2017-01-03 10:23 GMT+01:00 Benjamin Gaignard <benjamin.gaignard@linaro.org>:
> 2017-01-02 19:22 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
>> On 02/01/17 08:46, Benjamin Gaignard wrote:
>>> 2016-12-30 22:12 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
>>>> On 09/12/16 14:15, Benjamin Gaignard wrote:
>>>>> Timers IPs can be used to generate triggers for other IPs like
>>>>> DAC, ADC or other timers.
>>>>> Each trigger may result of timer internals signals like counter enable,
>>>>> reset or edge, this configuration could be done through "master_mode"
>>>>> device attribute.
>>>>>
>>>>> A timer device could be triggered by other timers, we use the trigger
>>>>> name and is_stm32_iio_timer_trigger() function to distinguish them
>>>>> and configure IP input switch.
>>>>>
>>>>> Timer may also decide on which event (edge, level) they could
>>>>> be activated by a trigger, this configuration is done by writing in
>>>>> "slave_mode" device attribute.
>>>>>
>>>>> Since triggers could also be used by DAC or ADC their names are defined
>>>>> in include/ nux/iio/timer/stm32-timer-trigger.h so those IPs will be able
>>>>> to configure themselves in valid_trigger function
>>>>>
>>>>> Trigger have a "sampling_frequency" attribute which allow to configure
>>>>> timer sampling frequency without using PWM interface
>>>>>
>>>>> version 5:
>>>>> - simplify tables of triggers
>>>>> - only create an IIO device when needed
>>>>>
>>>>> version 4:
>>>>> - get triggers configuration from "reg" in DT
>>>>> - add tables of triggers
>>>>> - sampling frequency is enable/disable when writing in trigger
>>>>> sampling_frequency attribute
>>>>> - no more use of interruptions
>>>>>
>>>>> version 3:
>>>>> - change compatible to "st,stm32-timer-trigger"
>>>>> - fix attributes access right
>>>>> - use string instead of int for master_mode and slave_mode
>>>>> - document device attributes in sysfs-bus-iio-timer-stm32
>>>>>
>>>>> version 2:
>>>>> - keep only one compatible
>>>>> - use st,input-triggers-names and st,output-triggers-names
>>>>> to know which triggers are accepted and/or create by the device
>>>> Firstly, sorry it has taken me so long to get back to this.
>>>>
>>>> I'm still not keen on this use of iio_device elements just to act as
>>>> glue between triggers. I think we need to work out a more light weight
>>>> way to do this. As you are only using them for validation and to provide
>>>> somewhere to hang the control attibutes off, there is nothing stopping us
>>>> moving that over to the iio_trigger instead which would avoid the messy
>>>> duality going on here.
>>>
>>> I have add an iio_device because each hardware can generate multiple
>>> triggers (up to 5: trgo, ch 1...4) and slave_mode attribute will impact all the
>>> triggers of a device. For me it was making sense to centralize that in an
>>> iio_device rather than having an attribute "shared" (from hardware
>>> point of view)
>>> on multiple triggers.
>>> Since master_mode attribute is only used by trgo and not impact ch1...4
>>> triggers I will move it to trigger instead of the iio_device.
>>>
>>> I also wanted to be able to connect triggers on a iio_device as I
>>> could do for an
>>> ADC with a command like 'echo "tim1_trgo" > iio_deviceX/trigger/current_trigger'
>> This is interesting, but with a bit of refactoring I would think it would
>> be possible to share some of that code thus allowing non IIO devices to
>> bind to triggers. Ultimately I want to be able to bind a trigger to
>> a trigger - I appreciate here the topology is more limited than that
>> so some complexity comes in.
>>
>> My gut feeling is that representing that topology explicitly is hard
>> to do in a remotely general way, but lets try it and see.
>> We run into this sort of interdependency issue between different bits of
>> the hardware all the time. Setting a value somewhere effects the configuration
>> elsewhere - often the best plan is to just let that happen and leave it up to
>> userspace to check for changes if it cares.
>
> okay
>
>>> If I change that to parent_trigger attribute it change this behavior
>>> and I will have to
>>> duplicated what is done in iio_trigger_write_current() to find and
>>> validate triggers.
>> I get the reasoning, but we still end up with something represented
>> by an IIO device that isn't providing any channels at all. It's simply
>> using some of the infrastructure. To my mind it is 'something else'
>> and should be represented as such. I have no problem at all with
>> you registering additional elements in /sysfs/bus/iio/ to represent
>> these shared elements - we already have drivers that do that to
>> provide some centralized infrastructure (e.g. the sysfs-trigger)
>
> My hardware block are timers maybe I can add a channel type "IIO_TIMER"
> and declare a channel with info_mask_separate = BIT(IIO_CHAN_INFO_SAMP_FREQ)
> so I will be able to write/read sampling frequency on IIO device.
>
If it isn't possible to implement IIO_TIMER I will simply drop device part of
my driver until we find a solution because I would like to upstream at
least what is
need to ADC/DAC.
>> I'm worried about the scope spread we get for an IIO device otherwise.
>> They serve a well defined purpose at the moment, and that isn't what
>> is happening here.
>>
>> So my gut feeling is we are better deliberately not representing the
>> inter dependence and claiming all triggers we are creating are
>> independent. That way we can have a nice generic infrastructure
>> that will work in all cases (be it pushing the sanity checking to
>> userspace).
>>
>> So each trigger has direct access to what controls it. Changing anything
>> can effect other triggers in weird ways.
>>
>> I'm finding it hard to see anything else generalizing sufficiently
>> as we'll always get cases where we can't represent the topology without
>> diving into the complexity of something like the media controller
>> framework.
>>
>> Jonathan
>>>
>>>> I might still be missing something though!
>>>>
>>>> You would only I think need 3 attributes
>>>>
>>>> parrent_trigger
>>>> and something like your master_mode and slave_mode attributes.
>>>>
>>>> The parrent_trigger would need some validation etc, but if we keep it
>>>> within this driver initially that won't be hard to do. Checking the device
>>>> parent matches will do most of it.
>>>>
>>>> Jonathan
>>>>>
>>>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>>> ---
>>>>> .../ABI/testing/sysfs-bus-iio-timer-stm32 | 55 +++
>>>>> drivers/iio/Kconfig | 2 +-
>>>>> drivers/iio/Makefile | 1 +
>>>>> drivers/iio/timer/Kconfig | 13 +
>>>>> drivers/iio/timer/Makefile | 1 +
>>>>> drivers/iio/timer/stm32-timer-trigger.c | 466 +++++++++++++++++++++
>>>>> drivers/iio/trigger/Kconfig | 1 -
>>>>> include/linux/iio/timer/stm32-timer-trigger.h | 62 +++
>>>>> 8 files changed, 599 insertions(+), 2 deletions(-)
>>>>> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>>>> create mode 100644 drivers/iio/timer/Kconfig
>>>>> create mode 100644 drivers/iio/timer/Makefile
>>>>> create mode 100644 drivers/iio/timer/stm32-timer-trigger.c
>>>>> create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
>>>>>
>>>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>>>> new file mode 100644
>>>>> index 0000000..26583dd
>>>>> --- /dev/null
>>>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>>>> @@ -0,0 +1,55 @@
>>>>> +What: /sys/bus/iio/devices/iio:deviceX/master_mode_available
>>>>> +KernelVersion: 4.10
>>>>> +Contact: benjamin.gaignard at st.com
>>>>> +Description:
>>>>> + Reading returns the list possible master modes which are:
>>>>> + - "reset" : The UG bit from the TIMx_EGR register is used as trigger output (TRGO).
>>>>> + - "enable" : The Counter Enable signal CNT_EN is used as trigger output.
>>>>> + - "update" : The update event is selected as trigger output.
>>>>> + For instance a master timer can then be used as a prescaler for a slave timer.
>>>>> + - "compare_pulse" : The trigger output send a positive pulse when the CC1IF flag is to be set.
>>>>> + - "OC1REF" : OC1REF signal is used as trigger output.
>>>>> + - "OC2REF" : OC2REF signal is used as trigger output.
>>>>> + - "OC3REF" : OC3REF signal is used as trigger output.
>>>>> + - "OC4REF" : OC4REF signal is used as trigger output.
>>>>> +
>>>>> +What: /sys/bus/iio/devices/iio:deviceX/master_mode
>>>>> +KernelVersion: 4.10
>>>>> +Contact: benjamin.gaignard at st.com
>>>>> +Description:
>>>>> + Reading returns the current master modes.
>>>>> + Writing set the master mode
>>>>> +
>>>>> +What: /sys/bus/iio/devices/iio:deviceX/slave_mode_available
>>>>> +KernelVersion: 4.10
>>>>> +Contact: benjamin.gaignard at st.com
>>>>> +Description:
>>>>> + Reading returns the list possible slave modes which are:
>>>>> + - "disabled" : The prescaler is clocked directly by the internal clock.
>>>>> + - "encoder_1" : Counter counts up/down on TI2FP1 edge depending on TI1FP2 level.
>>>>> + - "encoder_2" : Counter counts up/down on TI1FP2 edge depending on TI2FP1 level.
>>>>> + - "encoder_3" : Counter counts up/down on both TI1FP1 and TI2FP2 edges depending
>>>>> + on the level of the other input.
>>>>> + - "reset" : Rising edge of the selected trigger input reinitializes the counter
>>>>> + and generates an update of the registers.
>>>>> + - "gated" : The counter clock is enabled when the trigger input is high.
>>>>> + The counter stops (but is not reset) as soon as the trigger becomes low.
>>>>> + Both start and stop of the counter are controlled.
>>>>> + - "trigger" : The counter starts at a rising edge of the trigger TRGI (but it is not
>>>>> + reset). Only the start of the counter is controlled.
>>>>> + - "external_clock": Rising edges of the selected trigger (TRGI) clock the counter.
>>>>> +
>>>>> +What: /sys/bus/iio/devices/iio:deviceX/slave_mode
>>>>> +KernelVersion: 4.10
>>>>> +Contact: benjamin.gaignard at st.com
>>>>> +Description:
>>>>> + Reading returns the current slave mode.
>>>>> + Writing set the slave mode
>>>>> +
>>>>> +What: /sys/bus/iio/devices/triggerX/sampling_frequency
>>>>> +KernelVersion: 4.10
>>>>> +Contact: benjamin.gaignard at st.com
>>>>> +Description:
>>>>> + Reading returns the current sampling frequency.
>>>>> + Writing an value different of 0 set and start sampling.
>>>>> + Writing 0 stop sampling.
>>>>> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
>>>>> index 6743b18..2de2a80 100644
>>>>> --- a/drivers/iio/Kconfig
>>>>> +++ b/drivers/iio/Kconfig
>>>>> @@ -90,5 +90,5 @@ source "drivers/iio/potentiometer/Kconfig"
>>>>> source "drivers/iio/pressure/Kconfig"
>>>>> source "drivers/iio/proximity/Kconfig"
>>>>> source "drivers/iio/temperature/Kconfig"
>>>>> -
>>>>> +source "drivers/iio/timer/Kconfig"
>>>>> endif # IIO
>>>>> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
>>>>> index 87e4c43..b797c08 100644
>>>>> --- a/drivers/iio/Makefile
>>>>> +++ b/drivers/iio/Makefile
>>>>> @@ -32,4 +32,5 @@ obj-y += potentiometer/
>>>>> obj-y += pressure/
>>>>> obj-y += proximity/
>>>>> obj-y += temperature/
>>>>> +obj-y += timer/
>>>>> obj-y += trigger/
>>>>> diff --git a/drivers/iio/timer/Kconfig b/drivers/iio/timer/Kconfig
>>>>> new file mode 100644
>>>>> index 0000000..e3c21f2
>>>>> --- /dev/null
>>>>> +++ b/drivers/iio/timer/Kconfig
>>>>> @@ -0,0 +1,13 @@
>>>>> +#
>>>>> +# Timers drivers
>>>>> +
>>>>> +menu "Timers"
>>>>> +
>>>>> +config IIO_STM32_TIMER_TRIGGER
>>>>> + tristate "STM32 Timer Trigger"
>>>>> + depends on (ARCH_STM32 && OF && MFD_STM32_TIMERS) || COMPILE_TEST
>>>>> + select IIO_TRIGGERED_EVENT
>>>>> + help
>>>>> + Select this option to enable STM32 Timer Trigger
>>>>> +
>>>>> +endmenu
>>>>> diff --git a/drivers/iio/timer/Makefile b/drivers/iio/timer/Makefile
>>>>> new file mode 100644
>>>>> index 0000000..4ad95ec9
>>>>> --- /dev/null
>>>>> +++ b/drivers/iio/timer/Makefile
>>>>> @@ -0,0 +1 @@
>>>>> +obj-$(CONFIG_IIO_STM32_TIMER_TRIGGER) += stm32-timer-trigger.o
>>>>> diff --git a/drivers/iio/timer/stm32-timer-trigger.c b/drivers/iio/timer/stm32-timer-trigger.c
>>>>> new file mode 100644
>>>>> index 0000000..8d16e8f
>>>>> --- /dev/null
>>>>> +++ b/drivers/iio/timer/stm32-timer-trigger.c
>>>>> @@ -0,0 +1,466 @@
>>>>> +/*
>>>>> + * Copyright (C) STMicroelectronics 2016
>>>>> + *
>>>>> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>>> + *
>>>>> + * License terms: GNU General Public License (GPL), version 2
>>>>> + */
>>>>> +
>>>>> +#include <linux/iio/iio.h>
>>>>> +#include <linux/iio/sysfs.h>
>>>>> +#include <linux/iio/timer/stm32-timer-trigger.h>
>>>>> +#include <linux/iio/trigger.h>
>>>>> +#include <linux/iio/triggered_event.h>
>>>>> +#include <linux/interrupt.h>
>>>>> +#include <linux/mfd/stm32-timers.h>
>>>>> +#include <linux/module.h>
>>>>> +#include <linux/platform_device.h>
>>>>> +
>>>>> +#define MAX_TRIGGERS 6
>>>>> +#define MAX_VALIDS 5
>>>>> +
>>>>> +/* List the triggers created by each timer */
>>>>> +static const void *triggers_table[][MAX_TRIGGERS] = {
>>>>> + { TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4,},
>>>>> + { TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4,},
>>>>> + { TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4,},
>>>>> + { TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4,},
>>>>> + { TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4,},
>>>>> + { TIM6_TRGO,},
>>>>> + { TIM7_TRGO,},
>>>>> + { TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4,},
>>>>> + { TIM9_TRGO, TIM9_CH1, TIM9_CH2,},
>>>>> + { TIM12_TRGO, TIM12_CH1, TIM12_CH2,},
>>>>> +};
>>>>> +
>>>>> +/* List the triggers accepted by each timer */
>>>>> +static const void *valids_table[][MAX_VALIDS] = {
>>>>> + { TIM5_TRGO, TIM2_TRGO, TIM4_TRGO, TIM3_TRGO,},
>>>>> + { TIM1_TRGO, TIM8_TRGO, TIM3_TRGO, TIM4_TRGO,},
>>>>> + { TIM1_TRGO, TIM8_TRGO, TIM5_TRGO, TIM4_TRGO,},
>>>>> + { TIM1_TRGO, TIM2_TRGO, TIM3_TRGO, TIM8_TRGO,},
>>>>> + { TIM2_TRGO, TIM3_TRGO, TIM4_TRGO, TIM8_TRGO,},
>>>>> + { }, /* timer 6 */
>>>>> + { }, /* timer 7 */
>>>>> + { TIM1_TRGO, TIM2_TRGO, TIM4_TRGO, TIM5_TRGO,},
>>>>> + { TIM2_TRGO, TIM3_TRGO,},
>>>>> + { TIM4_TRGO, TIM5_TRGO,},
>>>>> +};
>>>>> +
>>>>> +struct stm32_timer_trigger {
>>>>> + struct device *dev;
>>>>> + struct regmap *regmap;
>>>>> + struct clk *clk;
>>>>> + u32 max_arr;
>>>>> + const void *triggers;
>>>>> + const void *valids;
>>>>> +};
>>>>> +
>>>>> +static int stm32_timer_start(struct stm32_timer_trigger *priv,
>>>>> + unsigned int frequency)
>>>>> +{
>>>>> + unsigned long long prd, div;
>>>>> + int prescaler = 0;
>>>>> + u32 ccer, cr1;
>>>>> +
>>>>> + /* Period and prescaler values depends of clock rate */
>>>>> + div = (unsigned long long)clk_get_rate(priv->clk);
>>>>> +
>>>>> + do_div(div, frequency);
>>>>> +
>>>>> + prd = div;
>>>>> +
>>>>> + /*
>>>>> + * Increase prescaler value until we get a result that fit
>>>>> + * with auto reload register maximum value.
>>>>> + */
>>>>> + while (div > priv->max_arr) {
>>>>> + prescaler++;
>>>>> + div = prd;
>>>>> + do_div(div, (prescaler + 1));
>>>>> + }
>>>>> + prd = div;
>>>>> +
>>>>> + if (prescaler > MAX_TIM_PSC) {
>>>>> + dev_err(priv->dev, "prescaler exceeds the maximum value\n");
>>>>> + return -EINVAL;
>>>>> + }
>>>>> +
>>>>> + /* Check if nobody else use the timer */
>>>>> + regmap_read(priv->regmap, TIM_CCER, &ccer);
>>>>> + if (ccer & TIM_CCER_CCXE)
>>>>> + return -EBUSY;
>>>>> +
>>>>> + regmap_read(priv->regmap, TIM_CR1, &cr1);
>>>>> + if (!(cr1 & TIM_CR1_CEN))
>>>>> + clk_enable(priv->clk);
>>>>> +
>>>>> + regmap_write(priv->regmap, TIM_PSC, prescaler);
>>>>> + regmap_write(priv->regmap, TIM_ARR, prd - 1);
>>>>> + regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_ARPE, TIM_CR1_ARPE);
>>>>> +
>>>>> + /* Force master mode to update mode */
>>>>> + regmap_update_bits(priv->regmap, TIM_CR2, TIM_CR2_MMS, 0x20);
>>>>> +
>>>>> + /* Make sure that registers are updated */
>>>>> + regmap_update_bits(priv->regmap, TIM_EGR, TIM_EGR_UG, TIM_EGR_UG);
>>>>> +
>>>>> + /* Enable controller */
>>>>> + regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, TIM_CR1_CEN);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +static void stm32_timer_stop(struct stm32_timer_trigger *priv)
>>>>> +{
>>>>> + u32 ccer, cr1;
>>>>> +
>>>>> + regmap_read(priv->regmap, TIM_CCER, &ccer);
>>>>> + if (ccer & TIM_CCER_CCXE)
>>>>> + return;
>>>>> +
>>>>> + regmap_read(priv->regmap, TIM_CR1, &cr1);
>>>>> + if (cr1 & TIM_CR1_CEN)
>>>>> + clk_disable(priv->clk);
>>>>> +
>>>>> + /* Stop timer */
>>>>> + regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, 0);
>>>>> + regmap_write(priv->regmap, TIM_PSC, 0);
>>>>> + regmap_write(priv->regmap, TIM_ARR, 0);
>>>>> +}
>>>>> +
>>>>> +static ssize_t stm32_tt_store_frequency(struct device *dev,
>>>>> + struct device_attribute *attr,
>>>>> + const char *buf, size_t len)
>>>>> +{
>>>>> + struct iio_trigger *trig = to_iio_trigger(dev);
>>>>> + struct stm32_timer_trigger *priv = iio_trigger_get_drvdata(trig);
>>>>> + unsigned int freq;
>>>>> + int ret;
>>>>> +
>>>>> + ret = kstrtouint(buf, 10, &freq);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> +
>>>>> + if (freq == 0) {
>>>>> + stm32_timer_stop(priv);
>>>>> + } else {
>>>>> + ret = stm32_timer_start(priv, freq);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + }
>>>>> +
>>>>> + return len;
>>>>> +}
>>>>> +
>>>>> +static ssize_t stm32_tt_read_frequency(struct device *dev,
>>>>> + struct device_attribute *attr, char *buf)
>>>>> +{
>>>>> + struct iio_trigger *trig = to_iio_trigger(dev);
>>>>> + struct stm32_timer_trigger *priv = iio_trigger_get_drvdata(trig);
>>>>> + u32 psc, arr, cr1;
>>>>> + unsigned long long freq = 0;
>>>>> +
>>>>> + regmap_read(priv->regmap, TIM_CR1, &cr1);
>>>>> + regmap_read(priv->regmap, TIM_PSC, &psc);
>>>>> + regmap_read(priv->regmap, TIM_ARR, &arr);
>>>>> +
>>>>> + if (psc && arr && (cr1 & TIM_CR1_CEN)) {
>>>>> + freq = (unsigned long long)clk_get_rate(priv->clk);
>>>>> + do_div(freq, psc);
>>>>> + do_div(freq, arr);
>>>>> + }
>>>>> +
>>>>> + return sprintf(buf, "%d\n", (unsigned int)freq);
>>>>> +}
>>>>> +
>>>>> +static IIO_DEV_ATTR_SAMP_FREQ(0660,
>>>>> + stm32_tt_read_frequency,
>>>>> + stm32_tt_store_frequency);
>>>>> +
>>>>> +static struct attribute *stm32_trigger_attrs[] = {
>>>>> + &iio_dev_attr_sampling_frequency.dev_attr.attr,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static const struct attribute_group stm32_trigger_attr_group = {
>>>>> + .attrs = stm32_trigger_attrs,
>>>>> +};
>>>>> +
>>>>> +static const struct attribute_group *stm32_trigger_attr_groups[] = {
>>>>> + &stm32_trigger_attr_group,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static char *master_mode_table[] = {
>>>>> + "reset",
>>>>> + "enable",
>>>>> + "update",
>>>>> + "compare_pulse",
>>>>> + "OC1REF",
>>>>> + "OC2REF",
>>>>> + "OC3REF",
>>>>> + "OC4REF"
>>>>> +};
>>>>> +
>>>>> +static ssize_t stm32_tt_show_master_mode(struct device *dev,
>>>>> + struct device_attribute *attr,
>>>>> + char *buf)
>>>>> +{
>>>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>>> + u32 cr2;
>>>>> +
>>>>> + regmap_read(priv->regmap, TIM_CR2, &cr2);
>>>>> + cr2 = (cr2 & TIM_CR2_MMS) >> TIM_CR2_MMS_SHIFT;
>>>>> +
>>>>> + return snprintf(buf, PAGE_SIZE, "%s\n", master_mode_table[cr2]);
>>>>> +}
>>>>> +
>>>>> +static ssize_t stm32_tt_store_master_mode(struct device *dev,
>>>>> + struct device_attribute *attr,
>>>>> + const char *buf, size_t len)
>>>>> +{
>>>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>>> + int i;
>>>>> +
>>>>> + for (i = 0; i < ARRAY_SIZE(master_mode_table); i++) {
>>>>> + if (!strncmp(master_mode_table[i], buf,
>>>>> + strlen(master_mode_table[i]))) {
>>>>> + regmap_update_bits(priv->regmap, TIM_CR2,
>>>>> + TIM_CR2_MMS, i << TIM_CR2_MMS_SHIFT);
>>>>> + return len;
>>>>> + }
>>>>> + }
>>>>> +
>>>>> + return -EINVAL;
>>>>> +}
>>>>> +
>>>>> +static IIO_CONST_ATTR(master_mode_available,
>>>>> + "reset enable update compare_pulse OC1REF OC2REF OC3REF OC4REF");
>>>>> +
>>>>> +static IIO_DEVICE_ATTR(master_mode, 0660,
>>>>> + stm32_tt_show_master_mode,
>>>>> + stm32_tt_store_master_mode,
>>>>> + 0);
>>>>> +
>>>>> +static char *slave_mode_table[] = {
>>>>> + "disabled",
>>>>> + "encoder_1",
>>>>> + "encoder_2",
>>>>> + "encoder_3",
>>>>> + "reset",
>>>>> + "gated",
>>>>> + "trigger",
>>>>> + "external_clock",
>>>>> +};
>>>>> +
>>>>> +static ssize_t stm32_tt_show_slave_mode(struct device *dev,
>>>>> + struct device_attribute *attr,
>>>>> + char *buf)
>>>>> +{
>>>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>>> + u32 smcr;
>>>>> +
>>>>> + regmap_read(priv->regmap, TIM_SMCR, &smcr);
>>>>> + smcr &= TIM_SMCR_SMS;
>>>>> +
>>>>> + return snprintf(buf, PAGE_SIZE, "%s\n", slave_mode_table[smcr]);
>>>>> +}
>>>>> +
>>>>> +static ssize_t stm32_tt_store_slave_mode(struct device *dev,
>>>>> + struct device_attribute *attr,
>>>>> + const char *buf, size_t len)
>>>>> +{
>>>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>>> + int i;
>>>>> +
>>>>> + for (i = 0; i < ARRAY_SIZE(slave_mode_table); i++) {
>>>>> + if (!strncmp(slave_mode_table[i], buf,
>>>>> + strlen(slave_mode_table[i]))) {
>>>>> + regmap_update_bits(priv->regmap,
>>>>> + TIM_SMCR, TIM_SMCR_SMS, i);
>>>>> + return len;
>>>>> + }
>>>>> + }
>>>>> +
>>>>> + return -EINVAL;
>>>>> +}
>>>>> +
>>>>> +static IIO_CONST_ATTR(slave_mode_available,
>>>>> +"disabled encoder_1 encoder_2 encoder_3 reset gated trigger external_clock");
>>>>> +
>>>>> +static IIO_DEVICE_ATTR(slave_mode, 0660,
>>>>> + stm32_tt_show_slave_mode,
>>>>> + stm32_tt_store_slave_mode,
>>>>> + 0);
>>>>> +
>>>>> +static struct attribute *stm32_timer_attrs[] = {
>>>>> + &iio_dev_attr_master_mode.dev_attr.attr,
>>>>> + &iio_const_attr_master_mode_available.dev_attr.attr,
>>>>> + &iio_dev_attr_slave_mode.dev_attr.attr,
>>>>> + &iio_const_attr_slave_mode_available.dev_attr.attr,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static const struct attribute_group stm32_timer_attr_group = {
>>>>> + .attrs = stm32_timer_attrs,
>>>>> +};
>>>>> +
>>>>> +static const struct iio_trigger_ops timer_trigger_ops = {
>>>>> + .owner = THIS_MODULE,
>>>>> +};
>>>>> +
>>>>> +static int stm32_setup_iio_triggers(struct stm32_timer_trigger *priv)
>>>>> +{
>>>>> + int ret;
>>>>> + const char * const *cur = priv->triggers;
>>>>> +
>>>>> + while (cur && *cur) {
>>>>> + struct iio_trigger *trig;
>>>>> +
>>>>> + trig = devm_iio_trigger_alloc(priv->dev, "%s", *cur);
>>>>> + if (!trig)
>>>>> + return -ENOMEM;
>>>>> +
>>>>> + trig->dev.parent = priv->dev->parent;
>>>>> + trig->ops = &timer_trigger_ops;
>>>>> + trig->dev.groups = stm32_trigger_attr_groups;
>>>>> + iio_trigger_set_drvdata(trig, priv);
>>>>> +
>>>>> + ret = devm_iio_trigger_register(priv->dev, trig);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + cur++;
>>>>> + }
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +/**
>>>>> + * is_stm32_timer_trigger
>>>>> + * @trig: trigger to be checked
>>>>> + *
>>>>> + * return true if the trigger is a valid stm32 iio timer trigger
>>>>> + * either return false
>>>>> + */
>>>>> +bool is_stm32_timer_trigger(struct iio_trigger *trig)
>>>>> +{
>>>>> + return (trig->ops == &timer_trigger_ops);
>>>>> +}
>>>>> +EXPORT_SYMBOL(is_stm32_timer_trigger);
>>>>> +
>>>>> +static int stm32_validate_trigger(struct iio_dev *indio_dev,
>>>>> + struct iio_trigger *trig)
>>>>> +{
>>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>>> + const char * const *cur = priv->valids;
>>>>> + unsigned int i = 0;
>>>>> +
>>>>> + if (!is_stm32_timer_trigger(trig))
>>>>> + return -EINVAL;
>>>>> +
>>>>> + while (cur && *cur) {
>>>>> + if (!strncmp(trig->name, *cur, strlen(trig->name))) {
>>>>> + regmap_update_bits(priv->regmap,
>>>>> + TIM_SMCR, TIM_SMCR_TS,
>>>>> + i << TIM_SMCR_TS_SHIFT);
>>>>> + return 0;
>>>>> + }
>>>>> + cur++;
>>>>> + i++;
>>>>> + }
>>>>> +
>>>>> + return -EINVAL;
>>>>> +}
>>>>> +
>>>>> +static const struct iio_info stm32_trigger_info = {
>>>>> + .driver_module = THIS_MODULE,
>>>>> + .validate_trigger = stm32_validate_trigger,
>>>>> + .attrs = &stm32_timer_attr_group,
>>>>> +};
>>>>> +
>>>>> +static struct stm32_timer_trigger *stm32_setup_iio_device(struct device *dev)
>>>>> +{
>>>>> + struct iio_dev *indio_dev;
>>>>> + int ret;
>>>>> +
>>>>> + indio_dev = devm_iio_device_alloc(dev,
>>>>> + sizeof(struct stm32_timer_trigger));
>>>>> + if (!indio_dev)
>>>>> + return NULL;
>>>>> +
>>>>> + indio_dev->name = dev_name(dev);
>>>>> + indio_dev->dev.parent = dev;
>>>>> + indio_dev->info = &stm32_trigger_info;
>>>>> + indio_dev->modes = INDIO_EVENT_TRIGGERED;
>>>>> + indio_dev->num_channels = 0;
>>>>> + indio_dev->dev.of_node = dev->of_node;
>>>>> +
>>>>> + ret = devm_iio_device_register(dev, indio_dev);
>>>>> + if (ret)
>>>>> + return NULL;
>>>>> +
>>>>> + return iio_priv(indio_dev);
>>>>> +}
>>>>> +
>>>>> +static int stm32_timer_trigger_probe(struct platform_device *pdev)
>>>>> +{
>>>>> + struct device *dev = &pdev->dev;
>>>>> + struct stm32_timer_trigger *priv;
>>>>> + struct stm32_timers *ddata = dev_get_drvdata(pdev->dev.parent);
>>>>> + unsigned int index;
>>>>> + int ret;
>>>>> +
>>>>> + if (of_property_read_u32(dev->of_node, "reg", &index))
>>>>> + return -EINVAL;
>>>>> +
>>>>> + if (index >= ARRAY_SIZE(triggers_table))
>>>>> + return -EINVAL;
>>>>> +
>>>>> + /* Create an IIO device only if we have triggers to be validated */
>>>>> + if (*valids_table[index])
>>>>> + priv = stm32_setup_iio_device(dev);
>>>>
>>>> I still don't like this. Really feels like we shouldn't be creating an
>>>> iio device with all the bagage that carries just to allow us to do the
>>>> trigger trees. We ought to have a much more light weight solution for this
>>>> functionality - we aren't typically even using the interrupt tree stuff
>>>> that the triggers for devices are all really about.
>>>>
>>>> A simpler approach of allowing each trigger the option of a parent seems like
>>>> it would be cleaner. Could be done entirely within this driver in the first
>>>> instance. Basically it would just look like your master and slave attributes
>>>> but have those under triggerX not iio:deviceX.
>>>>
>>>> We can work out how to make it more generic later - including perhaps the
>>>> option to trigger from triggers outside this driver, using some parallel
>>>> infrastructure to the device triggering.
>>>>
>>>>
>>>>> + else
>>>>> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>>>>> +
>>>>> + if (!priv)
>>>>> + return -ENOMEM;
>>>>> +
>>>>> + priv->dev = dev;
>>>>> + priv->regmap = ddata->regmap;
>>>>> + priv->clk = ddata->clk;
>>>>> + priv->max_arr = ddata->max_arr;
>>>>> + priv->triggers = triggers_table[index];
>>>>> + priv->valids = valids_table[index];
>>>>> +
>>>>> + ret = stm32_setup_iio_triggers(priv);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> +
>>>>> + platform_set_drvdata(pdev, priv);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +static const struct of_device_id stm32_trig_of_match[] = {
>>>>> + { .compatible = "st,stm32-timer-trigger", },
>>>>> + { /* end node */ },
>>>>> +};
>>>>> +MODULE_DEVICE_TABLE(of, stm32_trig_of_match);
>>>>> +
>>>>> +static struct platform_driver stm32_timer_trigger_driver = {
>>>>> + .probe = stm32_timer_trigger_probe,
>>>>> + .driver = {
>>>>> + .name = "stm32-timer-trigger",
>>>>> + .of_match_table = stm32_trig_of_match,
>>>>> + },
>>>>> +};
>>>>> +module_platform_driver(stm32_timer_trigger_driver);
>>>>> +
>>>>> +MODULE_ALIAS("platform: stm32-timer-trigger");
>>>>> +MODULE_DESCRIPTION("STMicroelectronics STM32 Timer Trigger driver");
>>>>> +MODULE_LICENSE("GPL v2");
>>>>> diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig
>>>>> index 809b2e7..f2af4fe 100644
>>>>> --- a/drivers/iio/trigger/Kconfig
>>>>> +++ b/drivers/iio/trigger/Kconfig
>>>>> @@ -46,5 +46,4 @@ config IIO_SYSFS_TRIGGER
>>>>>
>>>>> To compile this driver as a module, choose M here: the
>>>>> module will be called iio-trig-sysfs.
>>>>> -
>>>> Clean this up.
>>>
>>> ok
>>>
>>>>> endmenu
>>>>> diff --git a/include/linux/iio/timer/stm32-timer-trigger.h b/include/linux/iio/timer/stm32-timer-trigger.h
>>>>> new file mode 100644
>>>>> index 0000000..55535ae
>>>>> --- /dev/null
>>>>> +++ b/include/linux/iio/timer/stm32-timer-trigger.h
>>>>> @@ -0,0 +1,62 @@
>>>>> +/*
>>>>> + * Copyright (C) STMicroelectronics 2016
>>>>> + *
>>>>> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>>> + *
>>>>> + * License terms: GNU General Public License (GPL), version 2
>>>>> + */
>>>>> +
>>>>> +#ifndef _STM32_TIMER_TRIGGER_H_
>>>>> +#define _STM32_TIMER_TRIGGER_H_
>>>>> +
>>>>> +#define TIM1_TRGO "tim1_trgo"
>>>>> +#define TIM1_CH1 "tim1_ch1"
>>>>> +#define TIM1_CH2 "tim1_ch2"
>>>>> +#define TIM1_CH3 "tim1_ch3"
>>>>> +#define TIM1_CH4 "tim1_ch4"
>>>>> +
>>>>> +#define TIM2_TRGO "tim2_trgo"
>>>>> +#define TIM2_CH1 "tim2_ch1"
>>>>> +#define TIM2_CH2 "tim2_ch2"
>>>>> +#define TIM2_CH3 "tim2_ch3"
>>>>> +#define TIM2_CH4 "tim2_ch4"
>>>>> +
>>>>> +#define TIM3_TRGO "tim3_trgo"
>>>>> +#define TIM3_CH1 "tim3_ch1"
>>>>> +#define TIM3_CH2 "tim3_ch2"
>>>>> +#define TIM3_CH3 "tim3_ch3"
>>>>> +#define TIM3_CH4 "tim3_ch4"
>>>>> +
>>>>> +#define TIM4_TRGO "tim4_trgo"
>>>>> +#define TIM4_CH1 "tim4_ch1"
>>>>> +#define TIM4_CH2 "tim4_ch2"
>>>>> +#define TIM4_CH3 "tim4_ch3"
>>>>> +#define TIM4_CH4 "tim4_ch4"
>>>>> +
>>>>> +#define TIM5_TRGO "tim5_trgo"
>>>>> +#define TIM5_CH1 "tim5_ch1"
>>>>> +#define TIM5_CH2 "tim5_ch2"
>>>>> +#define TIM5_CH3 "tim5_ch3"
>>>>> +#define TIM5_CH4 "tim5_ch4"
>>>>> +
>>>>> +#define TIM6_TRGO "tim6_trgo"
>>>>> +
>>>>> +#define TIM7_TRGO "tim7_trgo"
>>>>> +
>>>>> +#define TIM8_TRGO "tim8_trgo"
>>>>> +#define TIM8_CH1 "tim8_ch1"
>>>>> +#define TIM8_CH2 "tim8_ch2"
>>>>> +#define TIM8_CH3 "tim8_ch3"
>>>>> +#define TIM8_CH4 "tim8_ch4"
>>>>> +
>>>>> +#define TIM9_TRGO "tim9_trgo"
>>>>> +#define TIM9_CH1 "tim9_ch1"
>>>>> +#define TIM9_CH2 "tim9_ch2"
>>>>> +
>>>>> +#define TIM12_TRGO "tim12_trgo"
>>>>> +#define TIM12_CH1 "tim12_ch1"
>>>>> +#define TIM12_CH2 "tim12_ch2"
>>>>> +
>>>>> +bool is_stm32_timer_trigger(struct iio_trigger *trig);
>>>>> +
>>>>> +#endif
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Benjamin Gaignard
>
> Graphic Study Group
>
> Linaro.org ? Open source software for ARM SoCs
>
> Follow Linaro: Facebook | Twitter | Blog
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/2] MAINTAINERS: extend PSCI entry to cover the newly add PSCI checker code
From: Sudeep Holla @ 2017-01-03 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483446768-26973-1-git-send-email-sudeep.holla@arm.com>
This patch extends the file entry for PSCI so that the newly added
PSCI checker module code is also covered.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cfff2c9e3d94..c7397bdef186 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9842,7 +9842,7 @@ M: Mark Rutland <mark.rutland@arm.com>
M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
L: linux-arm-kernel at lists.infradead.org
S: Maintained
-F: drivers/firmware/psci.c
+F: drivers/firmware/psci*.c
F: include/linux/psci.h
F: include/uapi/linux/psci.h
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] drivers: psci: annotate timer on stack to silence odebug messages
From: Sudeep Holla @ 2017-01-03 12:32 UTC (permalink / raw)
To: linux-arm-kernel
When DEBUG_OBJECTS config is enabled, we get the below odebug warnings:
ODEBUG: object is on stack, but not annotated
WARNING: CPU: 3 PID: 1304 at kernel/lib/debugobjects.c:300 __debug_object_init+0x1f0/0x458
CPU: 3 PID: 1304 Comm: psci_suspend_te Tainted: G W 4.9.0-06564-gf80f3f199260 #284
task: ffffe9e1b55a1600 task.stack: ffffe9e1b51c0000
PC is at __debug_object_init+0x1f0/0x458
LR is at __debug_object_init+0x1ec/0x458
Call trace:
__debug_object_init+0x1f0/0x458
debug_object_activate+0x150/0x260
mod_timer+0xb4/0x4c0
suspend_test_thread+0x1cc/0x3c0
kthread+0x110/0x140
ret_from_fork+0x10/0x40
This patch annotates the timer on the stack using setup_timer_on_stack
function to remove the above warnings.
Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/psci_checker.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/psci_checker.c b/drivers/firmware/psci_checker.c
index 44bdb78f837b..29d58feaf675 100644
--- a/drivers/firmware/psci_checker.c
+++ b/drivers/firmware/psci_checker.c
@@ -270,8 +270,7 @@ static int suspend_test_thread(void *arg)
struct cpuidle_device *dev;
struct cpuidle_driver *drv;
/* No need for an actual callback, we just want to wake up the CPU. */
- struct timer_list wakeup_timer =
- TIMER_INITIALIZER(dummy_callback, 0, 0);
+ struct timer_list wakeup_timer;
/* Wait for the main thread to give the start signal. */
wait_for_completion(&suspend_threads_started);
@@ -287,6 +286,7 @@ static int suspend_test_thread(void *arg)
pr_info("CPU %d entering suspend cycles, states 1 through %d\n",
cpu, drv->state_count - 1);
+ setup_timer_on_stack(&wakeup_timer, dummy_callback, 0);
for (i = 0; i < NUM_SUSPEND_CYCLE; ++i) {
int index;
/*
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH 1/2] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT
From: Catalin Marinas @ 2017-01-03 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481725151-20549-2-git-send-email-zhongjiang@huawei.com>
On Wed, Dec 14, 2016 at 10:19:10PM +0800, zhongjiang wrote:
> From: zhong jiang <zhongjiang@huawei.com>
>
> I think that CONT_PTE_SHIFT is more reasonable even if they are some
> value. and the patch is not any functional change.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> arch/arm64/mm/hugetlbpage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 2e49bd2..0a4c97b 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -323,7 +323,7 @@ static __init int setup_hugepagesz(char *opt)
> static __init int add_default_hugepagesz(void)
> {
> if (size_to_hstate(CONT_PTES * PAGE_SIZE) == NULL)
> - hugetlb_add_hstate(CONT_PMD_SHIFT);
> + hugetlb_add_hstate(CONT_PTE_SHIFT);
> return 0;
> }
> arch_initcall(add_default_hugepagesz);
It looks like I fixed this already when I merged some other hugetlb
patches. See commit 6ed0038d5ecb ("arm64: Fix typo in
add_default_hugepagesz() for 64K pages").
--
Catalin
^ permalink raw reply
* [PATCH v4 2/3] soc: zte: pm_domains: Add support for zx296718 board
From: kbuild test robot @ 2017-01-03 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483426577-5470-2-git-send-email-baoyou.xie@linaro.org>
Hi Baoyou,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc2 next-20161224]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Baoyou-Xie/soc-zte-pm_domains-Prepare-for-supporting-ARMv8-zx2967-family/20170103-181714
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> drivers/soc/zte/zx296718_pm_domains.c:7:47: fatal error: dt-bindings/soc/zx2967,pm_domains.h: No such file or directory
#include <dt-bindings/soc/zx2967,pm_domains.h>
^
compilation terminated.
vim +7 drivers/soc/zte/zx296718_pm_domains.c
1 /*
2 * Copyright (C) 2015 ZTE Ltd.
3 *
4 * Author: Baoyou Xie <baoyou.xie@linaro.org>
5 * License terms: GNU General Public License (GPL) version 2
6 */
> 7 #include <dt-bindings/soc/zx2967,pm_domains.h>
8 #include "zx2967_pm_domains.h"
9
10 static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 60343 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170103/2d453a38/attachment-0001.gz>
^ permalink raw reply
* [PATCH 1/4] input: Add support for the tm2 touchkey device driver
From: Javier Martinez Canillas @ 2017-01-03 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483430237-26823-2-git-send-email-jcsing.lee@samsung.com>
Hello Jaechul,
On 01/03/2017 04:57 AM, Jaechul Lee wrote:
> This patch adds the binding description of the tm2 touchkey
> device driver.
>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> ---
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v4 0/5] mfd: dt: Add bindings for the Aspeed MFDs
From: Lee Jones @ 2017-01-03 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e69b379-299f-ebf3-3a61-9ac1bcaba7b3@acm.org>
On Thu, 22 Dec 2016, Corey Minyard wrote:
> It looks like this is ready. Should I take this in the IPMI tree, or is
> there a better tree for it?
Please refrain from top posting.
Judging by the diff, it looks like the MFD tree would be the most
appropriate place to merge these into.
> On 12/20/2016 01:15 AM, Andrew Jeffery wrote:
> > Hi Lee,
> >
> > Here's v4 of the Aspeed LPC MFD devicetree bindings series. v3 can be found at:
> >
> > https://lkml.org/lkml/2016/12/5/835
> >
> > Changes since v3:
> >
> > * Based on Arnd's argument[1], drop the addition of the mfd/syscon bindings
> > directory as well as the the last patch in v3, which moved a number of
> > existing bindings. Eventually the Aspeed display controller will have a
> > device-specific driver so it doesn't belong there either.
> >
> > * Add a compatible string for the AST2400 in the LPC Host Controller bindings
> > as requested by Joel and slightly tweak the reg description for Rob.
> >
> > [1] https://lkml.org/lkml/2016/12/13/202
> >
> > Andrew Jeffery (5):
> > mfd: dt: Fix "indicates" typo in mfd bindings document
> > mfd: dt: ranges, #address-cells and #size-cells as optional properties
> > mfd: dt: Add Aspeed Low Pin Count Controller bindings
> > mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
> > mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
> >
> > .../devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++
> > .../devicetree/bindings/mfd/aspeed-lpc.txt | 137 +++++++++++++++++++++
> > Documentation/devicetree/bindings/mfd/mfd.txt | 12 +-
> > 3 files changed, 165 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> > create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 3/4] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Javier Martinez Canillas @ 2017-01-03 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103115530.zhjwn7bzmqmumy23@gangnam.samsung>
Hello Andi,
On 01/03/2017 08:55 AM, Andi Shyti wrote:
> Hi Chanwoo,
>
>>>>>>> Currently tm2e dts includes tm2 but there are some differences
>>>>>>> between the two boards and tm2 has some properties that tm2e
>>>>>>> doesn't have.
>>>>>>>
>>>>>>> That's why it's important to keep the two dts files independent
>>>>>>> and put all the commonalities in a tm2-common.dtsi file.
>>>>>>>
>>>>>>> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
>>>>>>> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
>>>>>>> ---
>>>>>>> .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1046 ++++++++++++++++++++
>>>>>>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1033 +------------------
>>>>>>> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 2 +-
>>>>>>> 3 files changed, 1049 insertions(+), 1032 deletions(-)
>>>>>>> create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>>>>>>
>
> [...]
>
>>> Because exynos5433-tm2.dts results modified, while
>>> exynos5433-tm2-common.dtsi is new. Even though I did:
>>>
>>> 1. mv exynos5433-tm2.dts exynos5433-tm2-common.dtsi
>>> 2. copied pieces from exynos5433-tm2-common.dtsi to a new
>>> exynos5433-tm2.dts
>>
>> I think that exynos5433-tm2-common.dtsi is not necessary because there
>> is small difference between TM2 and TM2E.
>>
>> I explain the detailed difference between TM2 and TM2E and then reply
>> how to support the TM2E board with existing exynos5433-tm2.dts file
>> without exynos5433-tm2-common.dtsi.
>>
>> Difference and the way to support TM2E with existing
>> exynos5433-tm2.dts file as following:
>> - hsi2c_9 is either used or not. TM2 uses the hsi2c_9 node for
>> touchkey. but TM2E do not use the hsi2c_9.
>> : We can just disable the hsi2c_9 node on tm2e.dts as following:
>>
>> &hsi2c_9 {
>> status = "disable";
>> };
>
> I thought about this alternative too, it just looked cleaner to
> me to have a tm2-common.dtsi file.
>
> Anyway, as you guys wish. If for you and Krzysztof is better this
> way, we can drop this patch and add the above lines in the current
> Jaechul's patch 4/4.
>
FWIW, I also agree with Chanwoo that the difference is too small to
need a common .dtsi file.
> Thanks,
> Andi
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6qdl-nitrogen6_max: fix sgtl5000 pinctrl init
From: Gary Bisson @ 2017-01-03 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103114316.GC20956@dragon>
Hi Shawn,
On Tue, Jan 03, 2017 at 07:43:17PM +0800, Shawn Guo wrote:
> On Tue, Jan 03, 2017 at 12:22:46PM +0100, Gary Bisson wrote:
> > This patch fixes the following error:
> > sgtl5000 0-000a: Error reading chip id -6
> > imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
> > imx-sgtl5000 sound: snd_soc_register_card failed (-517)
> >
> > The problem was that the pinctrl group was linked to the sound driver
> > instead of the codec node. Since the codec is probed first, the sys_mclk
> > was missing and it would therefore fail to initialize.
> >
> > Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
>
> Should we have it go as a fix for v4.10-rc cycles? In that case, please
> add a Fixes: tag. Also, do we need to apply it for stable kernel?
Sure it'd be great if it could be in v4.10.
Fixes: b32e700256bc ("ARM: dts: imx: add Boundary Devices Nitrogen6_Max board")
As for stable kernel, I guess it wouldn't hurt but it's not mandatory in
my opinion.
Do you want me to re-send with the Fixes line? What about the SOM2
patch, should it include a Fixes line although it works thanks to
U-Boot?
Thanks,
Gary
^ 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