* [PATCH v9 9/9] KVM: arm/arm64: Delete outdated forwarded irq documentation
From: Marc Zyngier @ 2017-12-27 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220113606.7030-10-christoffer.dall@linaro.org>
On Wed, 20 Dec 2017 11:36:06 +0000,
Christoffer Dall wrote:
>
> The reason I added this documentation originally was that the concept of
> "never taking the interrupt", but just use the timer to generate an exit
> from the guest, was confusing to most, and we had to explain it several
> times over. But as we can clearly see, we've failed to update the
> documentation as the code has evolved, and people who need to understand
> these details are probably better off reading the code.
>
> Let's lighten our maintenance burden slightly and just get rid of this.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt | 187 ---------------------
> 1 file changed, 187 deletions(-)
> delete mode 100644 Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
^ permalink raw reply
* [PATCH] Device tree binding for Avago APDS990X light sensor
From: Sakari Ailus @ 2017-12-27 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227091828.GA3307@amd>
Hi Pavel,
Thanks for the patch. Please see my comments below.
On Wed, Dec 27, 2017 at 10:18:28AM +0100, Pavel Machek wrote:
> From: Filip Matijevi? <filip.matijevic.pz@gmail.com>
>
> This prepares binding for light sensor used in Nokia N9.
>
> Signed-off-by: Filip Matijevi? <filip.matijevic.pz@gmail.com>
> Signed-off-by: Pavel machek <pavel@ucw.cz>
>
> ---
>
> Patches to convert APDS990X driver to device tree and to switch to iio
> are available.
>
> diff --git a/Documentation/devicetree/bindings/misc/avago-apds990x.txt b/Documentation/devicetree/bindings/misc/avago-apds990x.txt
> new file mode 100644
> index 0000000..e038146
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/avago-apds990x.txt
> @@ -0,0 +1,39 @@
> +Avago APDS990X driver
> +
> +Required properties:
> +- compatible: "avago,apds990x"
> +- reg: address on the I2C bus
> +- interrupts: external interrupt line number
> +- Vdd-supply: power supply for VDD
> +- Vled-supply: power supply for LEDA
AFAIK the custom is to use lower case letters for regulator supplies.
> +- ga: Glass attenuation
> +- cf1: Clear channel factor 1
> +- irf1: IR channel factor 1
> +- cf2: Clear channel factor 2
> +- irf2: IR channel factor 2
> +- df: Device factor
> +- pdrive: IR current, one of APDS_IRLED_CURR_XXXmA values
> +- ppcount: Proximity pulse count
Are these device specific? If so, please add the vendor prefix to them.
I might not use short abbreviations such as "df" either. I wonder what
others think.
> +
> +Example (Nokia N9):
> +
> + als_ps at 39 {
> + compatible = "avago,apds990x";
> + reg = <0x39>;
> +
> + interrupt-parent = <&gpio3>;
> + interrupts = <19 10>; /* gpio_83, IRQF_TRIGGER_FALLING | IRQF_TRIGGER_LOW */
> +
> + Vdd-supply = <&vaux1>;
> + Vled-supply = <&vbat>;
> +
> + ga = <168834>;
> + cf1 = <4096>;
> + irf1 = <7824>;
> + cf2 = <877>;
> + irf2 = <1575>;
> + df = <52>;
> +
> + pdrive = <0x2>; /* APDS_IRLED_CURR_25mA */
> + ppcount = <5>;
> + };
>
--
Kind regards,
Sakari Ailus
sakari.ailus at linux.intel.com
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: usb: add DT binding for RK3328 dwc3 controller
From: Heiko Stuebner @ 2017-12-27 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204094041.25439-1-heiko@sntech.de>
Am Montag, 4. Dezember 2017, 10:40:38 CET schrieb Heiko Stuebner:
> From: William Wu <william.wu@rock-chips.com>
>
> Adds the device tree bindings description for RK3328 and
> compatible USB DWC3 controller.
>
> Signed-off-by: William Wu <william.wu@rock-chips.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
applied all 4 with Felipe's Ack on patch1
^ permalink raw reply
* [PATCH v5 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622
From: Bjorn Helgaas @ 2017-12-27 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514336394-17747-3-git-send-email-honghui.zhang@mediatek.com>
On Wed, Dec 27, 2017 at 08:59:54AM +0800, honghui.zhang at mediatek.com wrote:
> From: Honghui Zhang <honghui.zhang@mediatek.com>
>
> The hardware default value of IDs and class type is not correct,
> fix that by setup the correct values before start up.
>
> Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> ---
> drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
> include/linux/pci_ids.h | 2 ++
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> index fc29a9a..62aac0ea 100644
> --- a/drivers/pci/host/pcie-mediatek.c
> +++ b/drivers/pci/host/pcie-mediatek.c
> @@ -74,6 +74,10 @@
>
> /* PCIe V2 per-port registers */
> #define PCIE_MSI_VECTOR 0x0c0
> +
> +#define PCIE_CONF_ID 0x100
> +#define PCIE_CONF_CLASS 0x104
> +
> #define PCIE_INT_MASK 0x420
> #define INTX_MASK GENMASK(19, 16)
> #define INTX_SHIFT 16
> @@ -393,6 +397,14 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
> val |= PCIE_CSR_LTSSM_EN(port->slot) |
> PCIE_CSR_ASPM_L1_EN(port->slot);
> writel(val, pcie->base + PCIE_SYS_CFG_V2);
> +
> + /* Set up vendor ID and device ID for MT7622*/
> + val = PCI_VENDOR_ID_MEDIATEK;
> + writel(val, port->base + PCIE_CONF_ID);
> +
> + /* Set up class code for MT7622 */
> + val = PCI_CLASS_BRIDGE_PCI << 16;
> + writel(val, port->base + PCIE_CONF_CLASS);
1) Your comments mention MT7622 specifically, but this code is run for
both mt2712-pcie and mt7622-pcie. If this code is safe and necessary
for both mt2712-pcie and mt7622-pcie, please remove the mention of
MT7622.
2) The first comment mentions both "vendor ID and device ID" but you
don't write the device ID. Since this code applies to both
mt2712-pcie and mt7622-pcie, my guess is that you don't *want* to
write the device ID. If that's the case, please fix the comment.
3) If you only need to set the vendor ID, you're performing a 32-bit
write (writel()) to update a 16-bit value. Please use writew()
instead.
4) If you only need to set the vendor ID, please use a definition like
"PCIE_CONF_VENDOR_ID" instead of the ambiguous "PCIE_CONF_ID".
5) If you only need to set the vendor ID, please update the changelog
to mention "vendor ID" specifically instead of the ambiguous "IDs".
6) Please add a space before the closing "*/" of the first comment.
7) PCI_CLASS_BRIDGE_PCI is for a PCI-to-PCI bridge, i.e., one that has
PCI on both the primary (upstream) side and the secondary (downstream)
side. That kind of bridge has a type 1 config header (see
PCI_HEADER_TYPE) and the PCI_PRIMARY_BUS and PCI_SECONDARY_BUS
registers tell us the bus number of the primary and secondary sides.
I don't believe this device is a PCI-to-PCI bridge. I think it's a
*host* bridge that has some non-PCI interface on the upstream side and
should have a type 0 config header. If that's the case you should use
PCI_CLASS_BRIDGE_HOST instead.
> }
>
> /* Assert all reset signals */
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index ab20dc5..2480b0e 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2113,6 +2113,8 @@
>
> #define PCI_VENDOR_ID_MYRICOM 0x14c1
>
> +#define PCI_VENDOR_ID_MEDIATEK 0x14c3
> +
> #define PCI_VENDOR_ID_TITAN 0x14D2
> #define PCI_DEVICE_ID_TITAN_010L 0x8001
> #define PCI_DEVICE_ID_TITAN_100L 0x8010
> --
> 2.6.4
>
^ permalink raw reply
* [PATCH] Device tree binding for Avago APDS990X light sensor
From: Filip Matijević @ 2017-12-27 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227180000.6ejpbqmr736nqx5i@kekkonen.localdomain>
Hi Sakari,
and thank you for your input - I've added a few comments below.
On 12/27/2017 07:00 PM, Sakari Ailus wrote:
> Hi Pavel,
>
> Thanks for the patch. Please see my comments below.
>
> On Wed, Dec 27, 2017 at 10:18:28AM +0100, Pavel Machek wrote:
>> From: Filip Matijevi? <filip.matijevic.pz@gmail.com>
>>
>> This prepares binding for light sensor used in Nokia N9.
>>
>> Signed-off-by: Filip Matijevi? <filip.matijevic.pz@gmail.com>
>> Signed-off-by: Pavel machek <pavel@ucw.cz>
>>
>> ---
>>
>> Patches to convert APDS990X driver to device tree and to switch to iio
>> are available.
>>
>> diff --git a/Documentation/devicetree/bindings/misc/avago-apds990x.txt b/Documentation/devicetree/bindings/misc/avago-apds990x.txt
>> new file mode 100644
>> index 0000000..e038146
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/avago-apds990x.txt
>> @@ -0,0 +1,39 @@
>> +Avago APDS990X driver
>> +
>> +Required properties:
>> +- compatible: "avago,apds990x"
>> +- reg: address on the I2C bus
>> +- interrupts: external interrupt line number
>> +- Vdd-supply: power supply for VDD
>> +- Vled-supply: power supply for LEDA
>
> AFAIK the custom is to use lower case letters for regulator supplies.
I've just used the same notation as in current driver. Datasheet calls
those VDD (with DD being in subscript) and LEDA. I see no problem in
changing those to vdd-supply and vled-supply if no one else objects.
>
>> +- ga: Glass attenuation
>> +- cf1: Clear channel factor 1
>> +- irf1: IR channel factor 1
>> +- cf2: Clear channel factor 2
>> +- irf2: IR channel factor 2
>> +- df: Device factor
>> +- pdrive: IR current, one of APDS_IRLED_CURR_XXXmA values
>> +- ppcount: Proximity pulse count
>
> Are these device specific? If so, please add the vendor prefix to them.
AFAIK yes - same as before if no one else objects, these will be changed.
>
> I might not use short abbreviations such as "df" either. I wonder what
> others think.
These are also come from current driver - some of these comes from the
datasheet itself, but not all. For example "ga" and "df" are in there
(so I I would leave those alone), but "irf1" is called "B", "cf2" is
called "C" and "irf2" is called "D" (I guess the missing "cf1" should be
"A", but there is no such thing in the datasheet).
IMHO using some other names might just add to the confusion.
>
>> +
>> +Example (Nokia N9):
>> +
>> + als_ps at 39 {
>> + compatible = "avago,apds990x";
>> + reg = <0x39>;
>> +
>> + interrupt-parent = <&gpio3>;
>> + interrupts = <19 10>; /* gpio_83, IRQF_TRIGGER_FALLING | IRQF_TRIGGER_LOW */
>> +
>> + Vdd-supply = <&vaux1>;
>> + Vled-supply = <&vbat>;
>> +
>> + ga = <168834>;
>> + cf1 = <4096>;
>> + irf1 = <7824>;
>> + cf2 = <877>;
>> + irf2 = <1575>;
>> + df = <52>;
>> +
>> + pdrive = <0x2>; /* APDS_IRLED_CURR_25mA */
>> + ppcount = <5>;
>> + };
>>
>
Best regards,
Filip
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6: RDU2: disable internal watchdog
From: Andrey Smirnov @ 2017-12-27 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AGrJ0f64mLQyjpbiZWusT+J6Q39Rc6+aN-hxX8Xe=R8A@mail.gmail.com>
On Wed, Dec 27, 2017 at 3:09 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Andrey,
>
> On Wed, Dec 27, 2017 at 1:56 AM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>> The system has an external watchdog in the environment processor
>> so the internal watchdog is of no use.
>>
>> Cc: Sascha Hauer <kernel@pengutronix.de>
>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree at vger.kernel.org
>> Cc: linux-kernel at vger.kernel.org
>> Cc: cphealy at gmail.com
>> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>
> Patch looks good.
>
> Just not clear if the authorship comes from you or Lucas.
>
> If Lucas is the original author then his name should appear in the From field.
Lucas is the original author and I am just a messenger. Sorry for the
confusion, will send a v2 with "From" fixed.
Sorry for the noise.
Thanks,
Andrey Smirnov
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx6: RDU2: correct RTC compatible
From: Andrey Smirnov @ 2017-12-27 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BO=kX6ZDLV75c44VPNOggLzf630SHcyzfAU_+4ME2vDQ@mail.gmail.com>
On Wed, Dec 27, 2017 at 3:11 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Andrey,
>
> On Wed, Dec 27, 2017 at 1:56 AM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>> The RTC is manufactured by Maxim. This is a cosmetic fix, as Linux
>> doesn't match the vendor string for i2c devices.
>>
>> Cc: Sascha Hauer <kernel@pengutronix.de>
>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree at vger.kernel.org
>> Cc: linux-kernel at vger.kernel.org
>> Cc: cphealy at gmail.com
>> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>
> This patch seems to be from Lucas:
> https://patchwork.kernel.org/patch/10099397/
>
> ,so his name should appear in the From field.
>
> Anyway, this patch has been sent earlier and we suggested to keep the
> existing binding, which is the documented form:
> https://patchwork.kernel.org/patch/10099397/
Yes, the patch is from Lucas and I was just being a messenger. And
understood and thanks for the info.
Sorry for the noise and disregard this patch.
Thanks,
Andrey Smirnov
^ permalink raw reply
* [PATCH V1 0/1] Fix kernel panic caused by device ID duplication presented to the IOMMU
From: Jayachandran C @ 2017-12-27 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7f7fca76-88f8-6ee7-c402-fe4300c62253@arm.com>
Hi Robin,
On Tue, Dec 19, 2017 at 04:34:46PM +0000, Robin Murphy wrote:
> Hi Tomasz,
>
> On 19/12/17 15:13, Tomasz Nowicki wrote:
> >Here is my lspci output of ThunderX2 for which I am observing kernel panic coming from
> >SMMUv3 driver -> arm_smmu_write_strtab_ent() -> BUG_ON(ste_live):
> >
> ># lspci -vt
> >-[0000:00]-+-00.0-[01-1f]--+ [...]
> > + [...]
> > \-00.0-[1e-1f]----00.0-[1f]----00.0 ASPEED Technology, Inc. ASPEED Graphics Family
> >
> >ASP device -> 1f:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family
> >PCI-Express to PCI/PCI-X Bridge -> 1e:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge
> >While setting up ASP device SID in IORT dirver:
> >iort_iommu_configure() -> pci_for_each_dma_alias()
> >we need to walk up and iterate over each device which alias transaction from
> >downstream devices.
> >
> >AST device (1f:00.0) gets BDF=0x1f00 and corresponding SID=0x1f00 from IORT.
> >Bridge (1e:00.0) is the first alias. Following PCI Express to PCI/PCI-X Bridge
> >spec: PCIe-to-PCI/X bridges alias transactions from downstream devices using
> >the subordinate bus number. For bridge (1e:00.0), the subordinate is equal
> >to 0x1f. This gives BDF=0x1f00 and SID=1f00 which is the same as downstream
> >device. So it is possible to have two identical SIDs. The question is what we
> >should do about such case. Presented patch prevents from registering the same
> >ID so that SMMUv3 is not complaining later on.
>
> Ooh, subtle :( There is logic in arm_smmu_attach_device() to tolerate
> grouped devices aliasing to the same ID, but I guess I overlooked the
> distinction of a device sharing an alias ID with itself. I'm not sure
> I really like trying to work around this in generic code, since
> fwspec->ids is essentially opaque data in a driver-specific format - in
> theory a driver is free to encode a single logical ID into multiple
> fwspec elements (I think I did that in an early draft of SMMUv2 SMR
> support), at which point this approach might corrupt things massively.
>
> Does the (untested) diff below suffice?
>
> Robin.
>
> ----->8-----diff --git a/drivers/iommu/arm-smmu-v3.c
> b/drivers/iommu/arm-smmu-v3.c
> index f122071688fd..d8a730d83401 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -1731,7 +1731,7 @@ static __le64 *arm_smmu_get_step_for_sid(struct
> arm_smmu_device *smmu, u32 sid)
>
> static void arm_smmu_install_ste_for_dev(struct iommu_fwspec *fwspec)
> {
> - int i;
> + int i, j;
> struct arm_smmu_master_data *master = fwspec->iommu_priv;
> struct arm_smmu_device *smmu = master->smmu;
>
> @@ -1739,6 +1739,13 @@ static void arm_smmu_install_ste_for_dev(struct
> iommu_fwspec *fwspec)
> u32 sid = fwspec->ids[i];
> __le64 *step = arm_smmu_get_step_for_sid(smmu, sid);
>
> + /* Bridged PCI devices may end up with duplicated IDs */
> + for (j = 0; j < i; j++)
> + if (fwspec->ids[j] == sid)
> + break;
> + if (j < i)
> + continue;
> +
> arm_smmu_write_strtab_ent(smmu, sid, step, &master->ste);
> }
> }
Here is another tested by if you need one more:
Tested-by: Jayachandran C. <jnair@caviumnetworks.com>
This fixes the crash below seen in ThunderX2 boards with Aspeed BMC (when
booted without iommu.passthrough). Since this is a regression that breaks
bootup on the platform, can you consider submitting this for the 4.15 cycle?
[ 84.729351] ------------[ cut here ]------------
[ 84.729354] kernel BUG at /home/ubuntu/linux/drivers/iommu/arm-smmu-v3.c:1201!
[ 84.729358] Internal error: Oops - BUG: 0 [#1] SMP
[ 84.729360] Modules linked in: ast(+) ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops qede(+) drm q
ed bnx2x(+) mpt3sas raid_class scsi_transport_sas sdhci_acpi mdio sdhci libcrc32c gpio_xlp
[ 84.729375] CPU: 190 PID: 1725 Comm: systemd-udevd Not tainted 4.15.0-rc5 #37
[ 84.729376] Hardware name: Cavium Inc. Unknown/Unknown, BIOS 1.0 11/08/2017
[ 84.729379] pstate: 80400009 (Nzcv daif +PAN -UAO)
[ 84.729388] pc : arm_smmu_write_strtab_ent+0x1f0/0x1f8
[ 84.729391] lr : arm_smmu_install_ste_for_dev+0x70/0xc8
[ 84.729392] sp : ffff00001f6e3730
[ 84.729393] x29: ffff00001f6e3730 x28: ffff809ecc0d2268
[ 84.729395] x27: 0000000000000018 x26: ffff00001f6e3910
[ 84.729397] x25: ffff809ecc0d2238 x24: ffff809ecdc94158
[ 84.729398] x23: 0000000000000018 x22: 0000000000001d00
[ 84.729400] x21: ffff809ecdc90018 x20: ffff809ecb5ef288
[ 84.729401] x19: ffff80beca480000 x18: ffff0000093b8c08
[ 84.729402] x17: ffff000008aeab70 x16: ffff00001f6e3a20
[ 84.729404] x15: 0000000000000000 x14: dead000000000100
[ 84.729405] x13: dead000000000200 x12: 0000000000000020
[ 84.729407] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
[ 84.729408] x9 : 0000000000000000 x8 : 0000000000000000
[ 84.729410] x7 : 0000000000000100 x6 : 0000000000000015
[ 84.729411] x5 : 0000000000000015 x4 : 0000000000000002
[ 84.729413] x3 : ffff809ecb5ef288 x2 : 0000000000000001
[ 84.729414] x1 : ffff000008691e30 x0 : ffff809ecc0d2238
[ 84.729418] Process systemd-udevd (pid: 1725, stack limit = 0x000000002c585821)
[ 84.729420] Call trace:
[ 84.729423] arm_smmu_write_strtab_ent+0x1f0/0x1f8
[ 84.729425] arm_smmu_install_ste_for_dev+0x70/0xc8
[ 84.729426] arm_smmu_attach_dev+0x100/0x2f8
[ 84.729431] __iommu_attach_device+0x54/0xe0
[ 84.729433] iommu_group_add_device+0x150/0x428
[ 84.729435] iommu_group_get_for_dev+0x84/0x180
[ 84.729436] arm_smmu_add_device+0x138/0x240
[ 84.729445] iort_iommu_configure+0x138/0x188
[ 84.729452] acpi_dma_configure+0x3c/0x80
[ 84.729456] dma_configure+0xb0/0xe0
[ 84.729462] driver_probe_device+0x1f0/0x4a8
[ 84.729464] __driver_attach+0x124/0x128
[ 84.729466] bus_for_each_dev+0x70/0xb0
[ 84.729467] driver_attach+0x30/0x40
[ 84.729469] bus_add_driver+0x248/0x2b8
[ 84.729471] driver_register+0x68/0x100
[ 84.729478] __pci_register_driver+0x5c/0x70
[ 84.729488] ast_init+0x30/0x1000 [ast]
[ 84.729494] do_one_initcall+0x5c/0x168
[ 84.729501] do_init_module+0x64/0x1f4
[ 84.729502] load_module+0x1e64/0x21e8
[ 84.729503] SyS_finit_module+0x108/0x118
[ 84.729505] el0_svc_naked+0x20/0x24
[ 84.729508] Code: 34ffff82 d4210000 d2800120 17ffffd8 (d4210000)
Thanks,
JC.
^ permalink raw reply
* [PATCH v6 1/8] arch: enable relative relocations for arm64, power, x86, s390 and x86
From: Linus Torvalds @ 2017-12-27 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227085033.22389-2-ard.biesheuvel@linaro.org>
On Wed, Dec 27, 2017 at 12:50 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 7da3e5c366a0..49ae5b43fe2b 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -156,7 +156,7 @@ SECTIONS
> CON_INITCALL
> SECURITY_INITCALL
> INIT_RAM_FS
> - *(.init.rodata.* .init.bss) /* from the EFI stub */
> + *(.init.rodata.* .init.bss .init.discard.*) /* EFI stub */
> }
> .exit.data : {
> ARM_EXIT_KEEP(EXIT_DATA)
Weren't you supposed to explain this part in the commit message?
It isn't obvious why this is mixed up with the Kconfig changes, and
somebody already asked about it. The commit message only talks about
the Kconfig changes, and then suddenly there's that odd vmlinux.lds.S
change in there...
Linus
^ permalink raw reply
* [PATCH v6 1/8] arch: enable relative relocations for arm64, power, x86, s390 and x86
From: Ard Biesheuvel @ 2017-12-27 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFyJg=-PfrVV1kw_bqKKd9Uk+q2FS4pqPp-og_DDbhhaFw@mail.gmail.com>
On 27 December 2017 at 19:54, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Dec 27, 2017 at 12:50 AM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
>> index 7da3e5c366a0..49ae5b43fe2b 100644
>> --- a/arch/arm64/kernel/vmlinux.lds.S
>> +++ b/arch/arm64/kernel/vmlinux.lds.S
>> @@ -156,7 +156,7 @@ SECTIONS
>> CON_INITCALL
>> SECURITY_INITCALL
>> INIT_RAM_FS
>> - *(.init.rodata.* .init.bss) /* from the EFI stub */
>> + *(.init.rodata.* .init.bss .init.discard.*) /* EFI stub */
>> }
>> .exit.data : {
>> ARM_EXIT_KEEP(EXIT_DATA)
>
> Weren't you supposed to explain this part in the commit message?
>
Oops. Apologies, I indeed forgot to update the commit log.
> It isn't obvious why this is mixed up with the Kconfig changes, and
> somebody already asked about it. The commit message only talks about
> the Kconfig changes, and then suddenly there's that odd vmlinux.lds.S
> change in there...
>
Yeah. It doesn't make sense to respin right away for just that, so I
will give people some time to respond, and respin in a week or so.
^ permalink raw reply
* [PATCH] Device tree binding for Avago APDS990X light sensor
From: Pavel Machek @ 2017-12-27 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227180000.6ejpbqmr736nqx5i@kekkonen.localdomain>
Hi!
> > +Required properties:
> > +- compatible: "avago,apds990x"
> > +- reg: address on the I2C bus
> > +- interrupts: external interrupt line number
> > +- Vdd-supply: power supply for VDD
> > +- Vled-supply: power supply for LEDA
>
> AFAIK the custom is to use lower case letters for regulator supplies.
>
> > +- ga: Glass attenuation
> > +- cf1: Clear channel factor 1
> > +- irf1: IR channel factor 1
> > +- cf2: Clear channel factor 2
> > +- irf2: IR channel factor 2
> > +- df: Device factor
> > +- pdrive: IR current, one of APDS_IRLED_CURR_XXXmA values
> > +- ppcount: Proximity pulse count
>
> Are these device specific? If so, please add the vendor prefix to them.
Well, whole binding is "vendor specific". Does it make sense to add
prefix in such case?
> I might not use short abbreviations such as "df" either. I wonder what
> others think.
I see.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171227/ff1c47f7/attachment.sig>
^ permalink raw reply
* [PATCH v6 2/8] module: use relative references for __ksymtab entries
From: Linus Torvalds @ 2017-12-27 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227085033.22389-3-ard.biesheuvel@linaro.org>
On Wed, Dec 27, 2017 at 12:50 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 52e611ab9a6c..fe752d365334 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -327,4 +327,15 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
> compiletime_assert(__native_word(t), \
> "Need native word sized stores/loads for atomicity.")
>
> +/*
> + * Force the compiler to emit 'sym' as a symbol, so that we can reference
> + * it from inline assembler. Necessary in case 'sym' could be inlined
> + * otherwise, or eliminated entirely due to lack of references that are
> + * visibile to the compiler.
> + */
> +#define __ADDRESSABLE(sym) \
> + static void *__attribute__((section(".discard.text"), used)) \
> + __PASTE(__discard_##sym, __LINE__)(void) \
> + { return (void *)&sym; } \
> +
> #endif /* __LINUX_COMPILER_H */
Isn't this logically the point where you should add the arm64
vmlinux.lds.S change, and explain how ".discard.text" turns into
".init.discard.text" for some odd arm64 reason?
Linus
^ permalink raw reply
* [PATCH v6 2/8] module: use relative references for __ksymtab entries
From: Ard Biesheuvel @ 2017-12-27 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFxqJqJq_7VUzBVTppgXFPc-8Ou55iLsZjp3fr6B2gRyTQ@mail.gmail.com>
On 27 December 2017 at 20:07, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Dec 27, 2017 at 12:50 AM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
>> index 52e611ab9a6c..fe752d365334 100644
>> --- a/include/linux/compiler.h
>> +++ b/include/linux/compiler.h
>> @@ -327,4 +327,15 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
>> compiletime_assert(__native_word(t), \
>> "Need native word sized stores/loads for atomicity.")
>>
>> +/*
>> + * Force the compiler to emit 'sym' as a symbol, so that we can reference
>> + * it from inline assembler. Necessary in case 'sym' could be inlined
>> + * otherwise, or eliminated entirely due to lack of references that are
>> + * visibile to the compiler.
>> + */
>> +#define __ADDRESSABLE(sym) \
>> + static void *__attribute__((section(".discard.text"), used)) \
>> + __PASTE(__discard_##sym, __LINE__)(void) \
>> + { return (void *)&sym; } \
>> +
>> #endif /* __LINUX_COMPILER_H */
>
> Isn't this logically the point where you should add the arm64
> vmlinux.lds.S change, and explain how ".discard.text" turns into
> ".init.discard.text" for some odd arm64 reason?
>
I tried to keep the generic patches generic, so perhaps I should just
put the arm64 vmlinux.lds.S change in a patch on its own?
^ permalink raw reply
* [PATCH v6 2/8] module: use relative references for __ksymtab entries
From: Linus Torvalds @ 2017-12-27 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-2NUzsakN2rcM_5fqD0ubr+6ZXSc+5sjZZPbU3wj_Xsg@mail.gmail.com>
On Wed, Dec 27, 2017 at 12:11 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> I tried to keep the generic patches generic, so perhaps I should just
> put the arm64 vmlinux.lds.S change in a patch on its own?
I guess it doesn't matter, but regardless of where it gets introduced
I would like to see the explanation for where the heck that magical
".init.discard.text" comes from. It's definitely not obvious from the
patches, and is presumably some odd arm64 special case.
Linus
^ permalink raw reply
* [PATCH v6 2/8] module: use relative references for __ksymtab entries
From: Ard Biesheuvel @ 2017-12-27 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFzygF6P3v5VxyBucZfn-tg58jeV6qwt0y7QGmmNiKYghQ@mail.gmail.com>
On 27 December 2017 at 20:13, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Dec 27, 2017 at 12:11 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>>
>> I tried to keep the generic patches generic, so perhaps I should just
>> put the arm64 vmlinux.lds.S change in a patch on its own?
>
> I guess it doesn't matter, but regardless of where it gets introduced
> I would like to see the explanation for where the heck that magical
> ".init.discard.text" comes from. It's definitely not obvious from the
> patches, and is presumably some odd arm64 special case.
>
This has to do with the EFI stub. x86 and ARM link it into the
decompressor, and so the code and data are not annotated as __init
(and doing so would involve modifying a lot of code). arm64 does not
have a decompressor, and so the EFI stub is linked into the kernel
proper. To make sure the code ends up in the .init segment, all
sections are prepended with .init at the object level, using objcopy.
Annoyingly, we need this because there is a single instance of a
special section that ends up in the EFI stub code: we build lib/sort.c
again as a EFI libstub object, and given that sort() is exported, we
end up with a ksymtab section in the EFI stub. The sort() thing has
caused issues before [0], so perhaps I should just clone sort.c into
drivers/firmware/efi/libstub and get rid of that hack.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29f9007b3182ab3f328a31da13e6b1c9072f7a95
^ permalink raw reply
* v4.15: camera problems on n900
From: Pavel Machek @ 2017-12-27 21:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
In v4.14, back camera on N900 works. On v4.15-rc1.. it works for few
seconds, but then I get repeated oopses.
On v4.15-rc0.5 (commit ed30b147e1f6e396e70a52dbb6c7d66befedd786),
camera does not start.
Any ideas what might be wrong there?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171227/4a951706/attachment.sig>
^ permalink raw reply
* [PATCH] Device tree binding for Avago APDS990X light sensor
From: Sakari Ailus @ 2017-12-27 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a5d43a9-27f5-bdbd-780f-6c6bc47fb987@gmail.com>
On Wed, Dec 27, 2017 at 07:50:42PM +0100, Filip Matijevi? wrote:
> Hi Sakari,
>
> and thank you for your input - I've added a few comments below.
>
> On 12/27/2017 07:00 PM, Sakari Ailus wrote:
> > Hi Pavel,
> >
> > Thanks for the patch. Please see my comments below.
> >
> > On Wed, Dec 27, 2017 at 10:18:28AM +0100, Pavel Machek wrote:
> >> From: Filip Matijevi? <filip.matijevic.pz@gmail.com>
> >>
> >> This prepares binding for light sensor used in Nokia N9.
> >>
> >> Signed-off-by: Filip Matijevi? <filip.matijevic.pz@gmail.com>
> >> Signed-off-by: Pavel machek <pavel@ucw.cz>
> >>
> >> ---
> >>
> >> Patches to convert APDS990X driver to device tree and to switch to iio
> >> are available.
> >>
> >> diff --git a/Documentation/devicetree/bindings/misc/avago-apds990x.txt b/Documentation/devicetree/bindings/misc/avago-apds990x.txt
> >> new file mode 100644
> >> index 0000000..e038146
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/misc/avago-apds990x.txt
> >> @@ -0,0 +1,39 @@
> >> +Avago APDS990X driver
> >> +
> >> +Required properties:
> >> +- compatible: "avago,apds990x"
> >> +- reg: address on the I2C bus
> >> +- interrupts: external interrupt line number
> >> +- Vdd-supply: power supply for VDD
> >> +- Vled-supply: power supply for LEDA
> >
> > AFAIK the custom is to use lower case letters for regulator supplies.
>
> I've just used the same notation as in current driver. Datasheet calls
> those VDD (with DD being in subscript) and LEDA. I see no problem in
> changing those to vdd-supply and vled-supply if no one else objects.
>
> >
> >> +- ga: Glass attenuation
> >> +- cf1: Clear channel factor 1
> >> +- irf1: IR channel factor 1
> >> +- cf2: Clear channel factor 2
> >> +- irf2: IR channel factor 2
> >> +- df: Device factor
> >> +- pdrive: IR current, one of APDS_IRLED_CURR_XXXmA values
> >> +- ppcount: Proximity pulse count
> >
> > Are these device specific? If so, please add the vendor prefix to them.
>
> AFAIK yes - same as before if no one else objects, these will be changed.
>
> >
> > I might not use short abbreviations such as "df" either. I wonder what
> > others think.
>
> These are also come from current driver - some of these comes from the
> datasheet itself, but not all. For example "ga" and "df" are in there
> (so I I would leave those alone), but "irf1" is called "B", "cf2" is
> called "C" and "irf2" is called "D" (I guess the missing "cf1" should be
> "A", but there is no such thing in the datasheet).
> IMHO using some other names might just add to the confusion.
Ack, datasheet names are fine.
You could also use a single property with all device specific coefficients
in a pre-defined order.
I don't have a strong opinion either way.
--
Regards,
Sakari Ailus
sakari.ailus at linux.intel.com
^ permalink raw reply
* [PATCH] Device tree binding for Avago APDS990X light sensor
From: Sakari Ailus @ 2017-12-27 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227200147.GB16799@amd>
On Wed, Dec 27, 2017 at 09:01:47PM +0100, Pavel Machek wrote:
> Hi!
>
> > > +Required properties:
> > > +- compatible: "avago,apds990x"
> > > +- reg: address on the I2C bus
> > > +- interrupts: external interrupt line number
> > > +- Vdd-supply: power supply for VDD
> > > +- Vled-supply: power supply for LEDA
> >
> > AFAIK the custom is to use lower case letters for regulator supplies.
> >
> > > +- ga: Glass attenuation
> > > +- cf1: Clear channel factor 1
> > > +- irf1: IR channel factor 1
> > > +- cf2: Clear channel factor 2
> > > +- irf2: IR channel factor 2
> > > +- df: Device factor
> > > +- pdrive: IR current, one of APDS_IRLED_CURR_XXXmA values
> > > +- ppcount: Proximity pulse count
> >
> > Are these device specific? If so, please add the vendor prefix to them.
>
> Well, whole binding is "vendor specific". Does it make sense to add
> prefix in such case?
Yes, it does. If you later find one or more of these are generic, you could
remove the vendor prefix. I doubt that'll happen though, these seem very
device specific parameters.
--
Sakari Ailus
sakari.ailus at linux.intel.com
^ permalink raw reply
* v4.15: camera problems on n900
From: Sakari Ailus @ 2017-12-27 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227210543.GA19719@amd>
On Wed, Dec 27, 2017 at 10:05:43PM +0100, Pavel Machek wrote:
> Hi!
>
> In v4.14, back camera on N900 works. On v4.15-rc1.. it works for few
> seconds, but then I get repeated oopses.
>
> On v4.15-rc0.5 (commit ed30b147e1f6e396e70a52dbb6c7d66befedd786),
> camera does not start.
>
> Any ideas what might be wrong there?
What kind of oopses do you get?
--
Sakari Ailus
sakari.ailus at linux.intel.com
^ permalink raw reply
* [PATCH] pinctrl/spear/plgpio: Delete two error messages for a failed memory allocation in plgpio_probe()
From: SF Markus Elfring @ 2017-12-27 21:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 27 Dec 2017 22:34:28 +0100
Omit extra messages for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/pinctrl/spear/pinctrl-plgpio.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/spear/pinctrl-plgpio.c b/drivers/pinctrl/spear/pinctrl-plgpio.c
index 6a0ed8ab33b9..d2123e396b29 100644
--- a/drivers/pinctrl/spear/pinctrl-plgpio.c
+++ b/drivers/pinctrl/spear/pinctrl-plgpio.c
@@ -519,10 +519,8 @@ static int plgpio_probe(struct platform_device *pdev)
int ret, irq;
plgpio = devm_kzalloc(&pdev->dev, sizeof(*plgpio), GFP_KERNEL);
- if (!plgpio) {
- dev_err(&pdev->dev, "memory allocation fail\n");
+ if (!plgpio)
return -ENOMEM;
- }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
plgpio->base = devm_ioremap_resource(&pdev->dev, res);
@@ -544,10 +542,8 @@ static int plgpio_probe(struct platform_device *pdev)
sizeof(*plgpio->csave_regs) *
DIV_ROUND_UP(plgpio->chip.ngpio, MAX_GPIO_PER_REG),
GFP_KERNEL);
- if (!plgpio->csave_regs) {
- dev_err(&pdev->dev, "csave registers memory allocation fail\n");
+ if (!plgpio->csave_regs)
return -ENOMEM;
- }
#endif
platform_set_drvdata(pdev, plgpio);
--
2.15.1
^ permalink raw reply related
* v4.15: camera problems on n900
From: Pavel Machek @ 2017-12-27 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227211718.favif66afztygfje@kekkonen.localdomain>
1;2802;0cOn Wed 2017-12-27 23:17:19, Sakari Ailus wrote:
> On Wed, Dec 27, 2017 at 10:05:43PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > In v4.14, back camera on N900 works. On v4.15-rc1.. it works for few
> > seconds, but then I get repeated oopses.
> >
> > On v4.15-rc0.5 (commit ed30b147e1f6e396e70a52dbb6c7d66befedd786),
> > camera does not start.
> >
> > Any ideas what might be wrong there?
>
> What kind of oopses do you get?
They seemed to be in unrelated processes -> not useful for
debugging. I tried again, but this time it hangs, similar way to
-rc0.5. (That might be good news).
Does it work for you on N9?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171227/e7892f96/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Sakari Ailus @ 2017-12-27 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221104935.663812085b616935ca3046de@magewell.com>
Hi Yong,
On Thu, Dec 21, 2017 at 10:49:35AM +0800, Yong wrote:
> Hi,
>
> On Tue, 19 Dec 2017 13:53:28 +0200
> Sakari Ailus <sakari.ailus@iki.fi> wrote:
>
> > Hi Yong,
> >
> > On Thu, Jul 27, 2017 at 01:01:36PM +0800, Yong Deng wrote:
> > > Add binding documentation for Allwinner V3s CSI.
> > >
> > > Signed-off-by: Yong Deng <yong.deng@magewell.com>
> >
> > DT bindings should precede the driver.
>
> OK.
>
> >
> > > ---
> > > .../devicetree/bindings/media/sun6i-csi.txt | 49 ++++++++++++++++++++++
> > > 1 file changed, 49 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > > new file mode 100644
> > > index 0000000..f8d83f6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > > @@ -0,0 +1,49 @@
> > > +Allwinner V3s Camera Sensor Interface
> > > +------------------------------
> > > +
> > > +Required properties:
> > > + - compatible: value must be "allwinner,sun8i-v3s-csi"
> >
> > What are sun6i and sun8i? Is this device first present in sun6i SoCs,
> > whereas you have only defined bindings for sun8i?
>
> Yes, some sun6i SoCs has the almost same CSI module.
> There is only V3s on my hand. So, I only tested it on V3s. But
> some people work on the others.
Ack.
>
> >
> > > + - reg: base address and size of the memory-mapped region.
> > > + - interrupts: interrupt associated to this IP
> > > + - clocks: phandles to the clocks feeding the CSI
> > > + * ahb: the CSI interface clock
> > > + * mod: the CSI module clock
> > > + * ram: the CSI DRAM clock
> > > + - clock-names: the clock names mentioned above
> > > + - resets: phandles to the reset line driving the CSI
> > > +
> > > +- ports: A ports node with endpoint definitions as defined in
> > > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> >
> > Please document mandatory and optional endpoint properties relevant for the
> > hardware.
>
> I have added below commit in my v3:
> Currently, the driver only support the parallel interface. So, a single port
> node with one endpoint and parallel bus is supported.
Please specify the exact properties that are relevant for the hardware. No
references should be made to the driver, the bindings are entirely
separate.
Are the non-parallel (CSI-2?) and parallel bus on the same interface? If
yes, they should probably use different endpoints, if not, then different
ports.
You could document the other bus or omit it now altogether, in which case
you'd only detail the parallel bus properties here.
>
> >
> > > +
> > > +Example:
> > > +
> > > + csi1: csi at 01cb4000 {
> > > + compatible = "allwinner,sun8i-v3s-csi";
> > > + reg = <0x01cb4000 0x1000>;
> > > + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&ccu CLK_BUS_CSI>,
> > > + <&ccu CLK_CSI1_SCLK>,
> > > + <&ccu CLK_DRAM_CSI>;
> > > + clock-names = "ahb", "mod", "ram";
> > > + resets = <&ccu RST_BUS_CSI>;
> > > +
> > > + port {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + /* Parallel bus endpoint */
> > > + csi1_ep: endpoint {
> > > + remote-endpoint = <&adv7611_ep>;
> > > + bus-width = <16>;
> > > + data-shift = <0>;
> > > +
> > > + /* If hsync-active/vsync-active are missing,
> > > + embedded BT.656 sync is used */
> > > + hsync-active = <0>; /* Active low */
> > > + vsync-active = <0>; /* Active low */
> > > + data-active = <1>; /* Active high */
> > > + pclk-sample = <1>; /* Rising */
> > > + };
> > > + };
> > > + };
> > > +
> >
> > --
> > Kind regards,
> >
> > Sakari Ailus
> > e-mail: sakari.ailus at iki.fi
>
>
> Thanks,
> Yong
--
Regards,
Sakari Ailus
e-mail: sakari.ailus at iki.fi
^ permalink raw reply
* [PATCH] pinctrl: spear: Delete an error message for a failed memory allocation in spear_pinctrl_probe()
From: SF Markus Elfring @ 2017-12-27 21:48 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 27 Dec 2017 22:44:04 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/pinctrl/spear/pinctrl-spear.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pinctrl/spear/pinctrl-spear.c b/drivers/pinctrl/spear/pinctrl-spear.c
index 4db52ba38d8d..efe79d3f7659 100644
--- a/drivers/pinctrl/spear/pinctrl-spear.c
+++ b/drivers/pinctrl/spear/pinctrl-spear.c
@@ -361,10 +361,8 @@ int spear_pinctrl_probe(struct platform_device *pdev,
return -ENODEV;
pmx = devm_kzalloc(&pdev->dev, sizeof(*pmx), GFP_KERNEL);
- if (!pmx) {
- dev_err(&pdev->dev, "Can't alloc spear_pmx\n");
+ if (!pmx)
return -ENOMEM;
- }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pmx->vbase = devm_ioremap_resource(&pdev->dev, res);
--
2.15.1
^ permalink raw reply related
* [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs
From: Rob Herring @ 2017-12-27 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fdb2ab5-1dca-c44c-b647-3388a8ecea81@codeaurora.org>
On Wed, Dec 27, 2017 at 4:20 AM, Sricharan R <sricharan@codeaurora.org> wrote:
> Hi Rob,
>
> On 12/26/2017 11:06 PM, Rob Herring wrote:
>> On Thu, Dec 21, 2017 at 5:53 AM, Sricharan R <sricharan@codeaurora.org> wrote:
>>> Hi Rob,
>>>
>>> On 12/21/2017 2:48 AM, Rob Herring wrote:
>>>> On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote:
>>>>> Hi Viresh,
>>>>>
>>>>> On 12/20/2017 8:56 AM, Viresh Kumar wrote:
>>>>>> On 19-12-17, 21:25, Sricharan R wrote:
>>>>>>> + cpu at 0 {
>>>>>>> + compatible = "qcom,krait";
>>>>>>> + enable-method = "qcom,kpss-acc-v1";
>>>>>>> + device_type = "cpu";
>>>>>>> + reg = <0>;
>>>>>>> + qcom,acc = <&acc0>;
>>>>>>> + qcom,saw = <&saw0>;
>>>>>>> + clocks = <&kraitcc 0>;
>>>>>>> + clock-names = "cpu";
>>>>>>> + cpu-supply = <&smb208_s2a>;
>>>>>>> + operating-points-v2 = <&cpu_opp_table>;
>>>>>>> + };
>>>>>>> +
>>>>>>> + qcom,pvs {
>>>>>>> + qcom,pvs-format-a;
>>>>>>> + };
>>>>>>
>>>>>> Not sure what Rob is going to say on that :)
>>>>>>
>>>>>
>>>>> Yes. Would be good to know the best way.
>>>>
>>>> Seems like this should be a property of an efuse node either implied by
>>>> the compatible or a separate property. What determines format A vs. B?
>>>>
>>>
>>> Yes, this efuse registers are part of the eeprom (qfprom) tied to the soc.
>>> So this property (details like bitfields and register offsets that it represents)
>>> can be put soc specific and nvmem apis can be used to read
>>> the registers. Does something like below look ok ?
>>>
>>> qcom,pvs {
>>> compatible = "qcom,pvs-ipq8064";
>>> nvmem-cells = <&pvs_efuse>;
>>> }
>>
>> Why do you need this node? It doesn't look like it corresponds to a
>> h/w block. It looks like you are just creating it to instantiate a
>> driver.
>>
>>> qfprom: qfprom at 700000 {
>>> compatible = "qcom,qfprom";
>>
>> Either this or...
>>
>>> reg = <0x00700000 0x1000>;
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> ranges;
>>> pvs_efuse: pvs {
>>
>> a compatible here should be specific enough so the OS can know what
>> the bits are.
>
> Infact the above "qcom,pvs" node is required mainly to act as a consumer
> for the nvmem data provider ("qcom,qfprom") (using nvmem-cells = <&pvs_efuse>)
> Then "qfprom" can be made to contain a "format_a" or "format_b" specific cell.
>
> So all that is needed is, nvmem-cells = <&pvs_efuse_phandle> needs to be available
> somewhere. The requirement is similar what is now done by "operating-points-v2-ti-cpu"
> and the ti-cpufreq.c. There "operating-points-v2-ti-cpu" node, contains the syscon
> register to read the efuse values. Similarly does defining a new
> "operating-points-v2-krait-cpu" which would contain the nvmem-cells property look ok ?
> This would avoid defining a new qcom,pvs node.
Yes, this seems reasonable.
>
> cpu at 0 {
> compatible = "qcom,krait";
> enable-method = "qcom,kpss-acc-v1";
> device_type = "cpu";
> reg = <0>;
> qcom,acc = <&acc0>;
> qcom,saw = <&saw0>;
> clocks = <&kraitcc 0>;
> clock-names = "cpu";
> cpu-supply = <&smb208_s2a>;
> operating-points-v2 = <&cpu_opp_table>;
> };
>
> cpu_opp_table: opp_table {
> compatible = "operating-points-v2-krait-cpu";
>
> nvmem-cells = <&pvs_efuse_format_a>;
> /*
> * Missing opp-shared property means CPUs switch DVFS states
> * independently.
> */
>
> opp-1400000000 {
> opp-hz = /bits/ 64 <1400000000>;
> opp-microvolt-speed0-pvs0-v0 = <1250000>;
> opp-microvolt-speed0-pvs1-v0 = <1175000>;
> opp-microvolt-speed0-pvs2-v0 = <1125000>;
> opp-microvolt-speed0-pvs3-v0 = <1050000>;
>
> };
> ...
> }
>
> qfprom: qfprom at 700000 {
> compatible = "qcom,qfprom";
> reg = <0x00700000 0x1000>;
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
> pvs_efuse_format_a: pvs {
> reg = <0xc0 0x8>;
> };
> }
>
> Regards,
> Sricharan
>
> --
> "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH net-next 0/6] net: mvpp2: 1000BaseX and 2000BaseX support
From: Antoine Tenart @ 2017-12-27 22:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
common PHY driver (cp110-comphy).
Thanks to theses patches the fourth network interface can be used on the
mcbin, and two patches are attached: one to describe the interface in
the mcbin device tree, and another one adding Ethernet aliases now that
the four interfaces are described.
This was tested on a mcbin.
Patches 1 and 2 should go through the PHY tree, patches 3 and 4 through
the net-next tree and patches 5 and 6 through the mvebu one.
Please note the two mvpp2 patches do not conflict with the ACPI series
Marcin sent a few days ago, and the two series can be processed in
parallel. (Marcin is aware of me sending this series).
Thanks!
Antoine
Antoine Tenart (5):
phy: add 2.5G SGMII mode to the phy_mode enum
phy: cp110-comphy: 2.5G SGMII mode
net: mvpp2: 1000baseX support
net: mvpp2: 2500baseX support
arm64: dts: marvell: mcbin: enable the fourth network interface
Yan Markman (1):
arm64: dts: marvell: add Ethernet aliases
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 6 ++
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 7 +++
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 15 +++++
drivers/net/ethernet/marvell/mvpp2.c | 67 +++++++++++++++++++----
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 +++++-
include/linux/phy/phy.h | 1 +
6 files changed, 100 insertions(+), 13 deletions(-)
--
2.14.3
^ 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