* SMR masking and PCI
From: Robin Murphy @ 2016-10-31 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB1321DED0E75BD607BB52889EFFAE0@HE1PR04MB1321.eurprd04.prod.outlook.com>
On 31/10/16 15:57, Diana Madalina Craciun wrote:
> Hi Robin,
>
> On 10/28/2016 07:16 PM, Robin Murphy wrote:
>> Hi Stuart,
>>
>> On 27/10/16 18:10, Stuart Yoder wrote:
>>> Hi Robin,
>>>
>>> A question about how the SMR masking defined in the arm,smmu binding
>>> relates to the PCI iommu-map.
>>>
>>> The #iommu-cells property defines the number of cells an "IOMMU specifier"
>>> takes and 2 is specified to be:
>>>
>>> SMMUs with stream matching support and complex masters
>>> may use a value of 2, where the second cell represents
>>> an SMR mask to combine with the ID in the first cell.
>>>
>>> An iommu-map entry is defined as:
>>>
>>> (rid-base,iommu,iommu-base,length)
>>>
>>> What seems to be currently missing in the iommu-map support is
>>> the possibility the case where #iommu-cells=<2>.
>> Indeed. The bindings have so far rather implicitly assumed the case of
>> #{msi,iommu}-cells = 1, and the code has followed suit.
>>
>>> In this case iommu-base which is an IOMMU specifier should
>>> occupy 2 cells. For example on an ls2085a we would want:
>>>
>>> iommu-map = <0x0 0x6 0x7 0x3ff 0x1
>>> 0x100 0x6 0x8 0x3ff 0x1>;
>>>
>>> ...to mask our stream IDs to 10 bits.
>>>
>>> This should work in theory and comply with the bindings, no?
>> In theory, but now consider:
>>
>> iommu-map = <0x0 0x6 0x7 0x3ff 0x2>;
>>
>> faced with ID 1. The input base is 0, the output base is the 2-cell
>> value 0x7000003ff, so the final ID value should be 0x700000400, right?
>>
>>> of_pci_map_rid() seems to have a hardcoded assumption that
>>> each field in the map is 4 bytes.
>> It does. I guess we should explicitly check that #{msi,iommu}-cells = 1
>> on the target node, and maybe clarify in the binding that that cell
>> should represent a plain linear ID value (although that's pretty obvious
>> from context IMO).
>>
>>> (Also, I guess that msi-map is not affected by this since it
>>> is not related to the IOMMU...but we do have common code
>>> handling both maps.)
>> I'd say it's definitely affected, since #msi-cells can equally be more
>> than 1, and encodes an equally opaque value.
>>
>> It seems pretty reasonable to me that we could extend the binding to
>> accommodate #cells > 1 iff length == 1. Mark?
>>
>> That said, is there a concrete need for this, i.e. do you actually have
>> one device with a single requester ID, which maps to multiple output IDs
>> (which differ only in the upper bits) in a non-predictable manner?
>>
> Actually in the example presented by Stuart, the SMR mask should be
> 0x7C00 (as 0 means that the bit is relevant for matching). So, we have
> the stream ID 7, but the SMMU 500 is appending the TBU bits which makes
> the stream ID look like 0x1407 (TBU 5). In our platform the relationship
> device-TBU is not exposed and documented.
To be fair, that's only the fault of the folks who neglected to document
it (and if this really was the anticipated use-case, possibly also the
integration folks for not simply using the 15-bit Stream ID
configuration and tying any extra bits off). The TBU IDs are still an
undeniable property of the hardware, and not exactly difficult to
discover either. For instance, an LS2085a has been running with the
following map for PCIe for quite some time:
/* Squash 8:5:3 BDF down to 2:2:3 */
iommu-map-mask = <0x031f>;
iommu-map = <0x000 &smmu 0x1400 0x20>,
<0x100 &smmu 0x1420 0x20>,
<0x200 &smmu 0x1440 0x20>,
<0x300 &smmu 0x1460 0x20>;
(with the obligatory hacks to program the PEX LUT entries to match, and
the SATA ICIDs not to alias as they apparently go through the same TBU).
> The SMMU-500 ref manual
> describes this case:
>
> "If the Stream ID presented to each TBU is already unique, and the TBU
> ID addition is not required, then you must ensure that the TBU ID field
> is masked in the SMR."
>
> This is the reason that we need the SMR mask, to mask the TBU bits in
> the SMR.
The PCIe example might be a reason to *want* masking, in order to work
around inadequate documentation, but it certainly isn't a *need*.
Fortunately, Stuart's description of the DPAA complex mastering through
multiple TBUs such that a single device's ICID may map to multiple
stream IDs *is* a compelling justification, because iommu-map isn't
designed for one-to-many mappings. You just need to be very careful the
ICIDs really are completely unique system-wide once you start masking,
or the aliasing will result in weird, and possibly impractical, group
assignment.
Anyway, from the SMMU driver perspective SMR masking does work nicely
now, so I'm happy to review patches to of_pci_map_rid() ;)
Robin.
>
> Thank you,
>
> Diana
>
>
>
^ permalink raw reply
* [PATCH] staging: vc04_services: setup DMA and coherent mask
From: Eric Anholt @ 2016-10-31 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028171159.23973-1-mzoran@crowfest.net>
Michael Zoran <mzoran@crowfest.net> writes:
> Setting the DMA mask is optional on 32 bit but
> is mandatory on 64 bit. Set the DMA mask and coherent
> to force all DMA to be in the 32 bit address space.
>
> This is considered a "good practice" and most drivers
> already do this.
>
> Signed-off-by: Michael Zoran <mzoran@crowfest.net>
> ---
> .../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> index a5afcc5..6fa2b5a 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> @@ -97,6 +97,16 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
> int slot_mem_size, frag_mem_size;
> int err, irq, i;
>
> + /*
> + * Setting the DMA mask is necessary in the 64 bit environment.
> + * It isn't necessary in a 32 bit environment but is considered
> + * a good practice.
> + */
> + err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
I think a better comment here would be simply:
/* VCHI messages between the CPU and firmware use 32-bit bus addresses. */
explaining why the value is chosen (once you know that the 32 bit
restriction exists, reporting it is obviously needed). I'm curious,
though: what failed when you didn't set it?
> +
> + if (err < 0)
> + return err;
> +
> (void)of_property_read_u32(dev->of_node, "cache-line-size",
> &g_cache_line_size);
> g_fragments_size = 2 * g_cache_line_size;
> --
> 2.10.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/9e41b8fa/attachment.sig>
^ permalink raw reply
* [PATCH] staging: vc04_services: call sg_init_table to init scatterlist
From: Eric Anholt @ 2016-10-31 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028175813.28022-1-mzoran@crowfest.net>
Michael Zoran <mzoran@crowfest.net> writes:
> Call the sg_init_table function to correctly initialze
> the DMA scatterlist. This function is required to completely
> initialize the list and is mandatory if DMA debugging is
> enabled in the build configuration.
>
> One of the purposes of sg_init_table is to set
> the magic "cookie" on each list element and ensure
> the chain end is marked.
>
> Signed-off-by: Michael Zoran <mzoran@crowfest.net>
> ---
> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> index 6fa2b5a..21b26e5 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> @@ -464,6 +464,12 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
> pagelist->type = type;
> pagelist->offset = offset;
>
> + /*
> + * Initialize the scatterlist so that the magic cookie
> + * is filled if debugging is enabled
> + */
> + sg_init_table(scatterlist, num_pages);
> + /* Now set the pages for each scatterlist */
I feel like the comments don't add much, but either way:
Acked-by: Eric Anholt <eric@anholt.net>
> for (i = 0; i < num_pages; i++)
> sg_set_page(scatterlist + i, pages[i], PAGE_SIZE, 0);
>
> --
> 2.10.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/620e7f68/attachment.sig>
^ permalink raw reply
* [PATCH] pinctrl: meson: Add GXL pinctrl definitions
From: Kevin Hilman @ 2016-10-31 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477931531-27120-1-git-send-email-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Add support for the Amlogic Meson GXL SoC, this is a partially complete
> definition only based on the Amlogic Vendor tree.
>
> This definition differs a lot from the GXBB and needs a separate entry.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Bartlomiej Zolnierkiewicz @ 2016-10-31 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2291876.8LAt3RcuXX@amdc3058>
On Monday, October 31, 2016 07:14:13 PM Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Monday, October 31, 2016 03:46:22 PM Russell King - ARM Linux wrote:
> > On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > Hi,
> > >
> > > On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote:
> > > > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > >
> > > > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> > > > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > > > > This patch disables deprecated IDE subsystem in assabet_defconfig
> > > > > > > (no IDE host drivers are selected in this config so there is no
> > > > > > > valid reason to enable IDE subsystem itself).
> > > > > > >
> > > > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > > > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > > > >
> > > > > > I think the series makes a lot of sense. I have checked your assertions
> > > > > > in the changelogs and found no flaws in your logic, so I think we should
> > > > > > take them all through arm-soc unless there are other concerns.
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Should I resend everything or just patches that were not reposted yet
> > > > > (the ones that were marked as RFT initially and got no feedback)?
> > > >
> > > > I'd be fine with just getting a pull request with all the patches that
> > > > had no negative feedback and that were not already applied (if any).
> > >
> > > Here it is (sorry for taking so long).
> >
> > I've just been digging in the dmesg logs from when I was using the
> > Assabet+Neponset as my firewall, and it was having to use the IDE
> > ide-cs driver rather than the pata pcmcia driver.
> >
> > I don't recall whether the pata pcmcia driver was a problem or not,
> > as the PCMCIA interface can't cope with _any_ 32-bit accesses. I
> > think PATA tries to use the "highest" possible access size by
> > default...
>
> It doesn't actually - it defaults to 16-bits for PIO data access and
> you must explicitly enable 32-bits using ATA_PFLAG_PIO32 port flag
> (pata_pcmcia doesn't set it so it should be okay). Also taskfile
> registers are accessed using 8-bits access by default transport
> functions (which are used by pata_pcmcia).
Please also note that:
- assebet_defconfig currently doesn't even enable ide-cs
(CONFIG_BLK_DEV_IDECS) in the mainline kernel
- neponset_defconfig doesn't even enable IDE (CONFIG_IDE)
in the mainline kernel
so there is no risk of breaking anything.. :-)
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH v12 RESEND 0/4] generic TEE subsystem
From: Andrew F. Davis @ 2016-10-31 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161029094641.GA23362@ermac>
On 10/29/2016 04:46 AM, Jens Wiklander wrote:
> On Fri, Oct 28, 2016 at 10:43:24AM -0500, Andrew F. Davis wrote:
>> On 10/28/2016 05:19 AM, Jens Wiklander wrote:
>>> Hi,
>>>
>>> This patch set introduces a generic TEE subsystem. The TEE subsystem will
>>> contain drivers for various TEE implementations. A TEE (Trusted Execution
>>> Environment) is a trusted OS running in some secure environment, for
>>> example, TrustZone on ARM CPUs, or a separate secure co-processor etc.
>>>
>>> Regarding use cases, TrustZone has traditionally been used for
>>> offloading secure tasks to the secure world. Examples include:
>>> - Secure key handling where the OS may or may not have direct access to key
>>> material.
>>> - E-commerce and payment technologies. Credentials, credit card numbers etc
>>> could be stored in a more secure environment.
>>> - Trusted User Interface (TUI) to ensure that no-one can snoop PIN-codes
>>> etc.
>>> - Secure boot to ensure that loaded binaries haven?t been tampered with.
>>> It?s not strictly needed for secure boot, but you could enhance security
>>> by leveraging a TEE during boot.
>>> - Digital Rights Management (DRM), the studios provides content with
>>> different resolution depending on the security of the device. Higher
>>> security means higher resolution.
>>>
>>> A TEE could also be used in existing and new technologies. For example IMA
>>> (Integrity Measurement Architecture) which has been in the kernel for quite
>>> a while. Today you can enhance security by using a TPM-chip to sign the IMA
>>> measurement list. This is something that you also could do by leveraging a
>>> TEE.
>>>
>>> Another example could be in 2-factor authentication which is becoming
>>> increasingly more important. FIDO (https://fidoalliance.org) for example
>>> are using public key cryptography in their 2-factor authentication standard
>>> (U2F). With FIDO, a private and public key pair will be generated for every
>>> site you visit and the private key should never leave the local device.
>>> This is an example where you could use secure storage in a TEE for the
>>> private key.
>>>
>>> Today you will find a quite a few different out of tree implementations of
>>> TEE drivers which tends to fragment the TEE ecosystem and development. We
>>> think it would be a good idea to have a generic TEE driver integrated in
>>> the kernel which would serve as a base for several different TEE solutions,
>>> no matter if they are on-chip like TrustZone or if they are on a separate
>>> crypto co-processor.
>>>
>>> To develop this TEE subsystem we have been using the open source TEE called
>>> OP-TEE (https://github.com/OP-TEE/optee_os) and therefore this would be the
>>> first TEE solution supported by this new subsystem. OP-TEE is a
>>> GlobalPlatform compliant TEE, however this TEE subsystem is not limited to
>>> only GlobalPlatform TEEs, instead we have tried to design it so that it
>>> should work with other TEE solutions also.
>>>
>>
>> The above is my biggest concern with this whole subsystem, to me it
>> still feels very OPTEE specific. As much as I would love to believe
>> OPTEE will be the end-all TEE, I'm sure we soon will start to see wider
>> use of vendor TEEs (like TI's own legacy Trustzone thing we are hoping
>> to depreciate with OPTEE moving forward), possibly Google's Trusty TEE,
>> and whatever Intel/AMD are cooking up for x86.
>
> I'd rather say that it's slightly GlobalPlatform specific, but a bit
> more flexible.
>
>>
>> As we all know when things are upstreamed we lose the ability to make
>> radical changes easily, especially to full subsystems. What happens when
>> this framework, built with only one existing TEE, built by the one
>> existing TEE's devs, is not as flexible as we need when other TEEs start
>> rolling out?
>
> Initially the TEE subsystem was much more flexible and was criticized
> for that.
>
That's rather strange, I haven't been following this from the start so I
will just take your word that this is where the community wants this
subsystem to go.
>>
>> Do we see this as a chicken and egg situation, or is there any harm
>> beyond the pains of supporting an out-of-tree driver for a while, to
>> wait until we have at least one other TEE to add to this subsystem
>> before merging?
>
> This proposal is the bare minimum to have something useful. On top of
> this there's more things we'd like to add, for example an in-kernel API
> for accessing the TEE and secure buffer handling. The way we're dealing
> with shared memory need to be improved to better support multiple guests
> communicating with one TEE.
>
> What we can do now with the subsystem now is somewhat limited by the
> fact that we're trying to upstream it and want to do that it in
> manageable increments.
>
Fair enough.
For now this series is being used in our production SDKs so it has at
least some basic testing from us, so for the whole series:
Tested-by: Andrew F. Davis <afd@ti.com>
> Thanks,
> Jens
>
>>
>> This may also help with the perceived lack of reviewers for this series.
>>
>> Thanks,
>> Andrew
>>
>>> "tee: generic TEE subsystem" brings in the generic TEE subsystem which
>>> helps when writing a driver for a specific TEE, for example, OP-TEE.
>>>
>>> "tee: add OP-TEE driver" is an OP-TEE driver which uses the subsystem to do
>>> its work.
>>>
>>> This patch set has been prepared in cooperation with Javier Gonz?lez who
>>> proposed "Generic TrustZone Driver in Linux Kernel" patches 28 Nov 2014,
>>> https://lwn.net/Articles/623380/ . We've since then changed the scope to
>>> TEE instead of TrustZone.
>>>
>>> We have discussed the design on tee-dev at lists.linaro.org (archive at
>>> https://lists.linaro.org/pipermail/tee-dev/) with people from other
>>> companies, including Valentin Manea <valentin.manea@huawei.com>,
>>> Emmanuel MICHEL <emmanuel.michel@st.com>,
>>> Jean-michel DELORME <jean-michel.delorme@st.com>,
>>> and Joakim Bech <joakim.bech@linaro.org>. Our main concern has been to
>>> agree on something that is generic enough to support many different
>>> TEEs while still keeping the interface together.
>>>
>>> v12-resend:
>>> * Rebased on v4.9-rc2
>>>
>>> v12:
>>> * Rebased on v4.8-rc5
>>> * Addressed review comments from Andrew F. Davis
>>> * Removed Acked-by: Andreas Dannenberg <dannenberg@ti.com> as the
>>> mail bounces
>>> * Bugfix possible null dereference in error cleanup path of
>>> optee_probe().
>>> * Bugfix optee_from_msg_param() when calculating offset of memref
>>> into a shared memory object
>>>
>>> v11:
>>> * Rebased on v4.8-rc3
>>> * Addressed review comments from Nishanth Menon
>>> * Made the TEE framework available as a loadable module.
>>> * Reviewed-by: Javier Gonz?lez <javier@javigon.com>
>>> * Zeroes shared memory on allocation to avoid information leakage
>>> * Links shared memory objects to context to avoid stealing of shared memory
>>> object from an unrelated process
>>> * Allow RPC interruption if supplicant is unavailable
>>>
>>> v10:
>>> * Rebased on v4.7-rc1
>>> * Addressed private review comments from Nishanth Menon
>>> * Optee driver only accepts one supplicant process on the privileged device
>>> * Optee driver avoids long delayed releases of shm objects
>>> * Added more comments on functions and structs
>>>
>>> v9:
>>> * Rebased on v4.6-rc1
>>> * Acked-by: Andreas Dannenberg <dannenberg@ti.com>
>>> * Addressed comments from Al Viro how file descriptors are passed to
>>> user space
>>> * Addressed comments from Randy Dunlap on documentation
>>> * Changed license for include/uapi/linux/tee.h
>>>
>>> v8:
>>> * Rebased on v4.5-rc3
>>> * dt/bindings: add bindings for optee
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> * Fixes build error for X86
>>> * Fixes spell error in "dt/bindings: add bindings for optee"
>>>
>>> v7:
>>> * Rebased on v4.5-rc2
>>> * Moved the ARM SMC Calling Convention support into a separate patch
>>> set, which is now merged
>>>
>>> v6:
>>> * Rebased on v4.3-rc7
>>> * Changed smccc interface to let the compiler marshal most of the
>>> parameters
>>> * Added ARCH64 capability for smccc interface
>>> * Changed the PSCI firmware calls (both arm and arm64) to use the new
>>> generic smccc interface instead instead of own assembly functions.
>>> * Move optee DT bindings to below arm/firmware
>>> * Defines method for OP-TEE driver to call secure world in DT, smc or hvc
>>> * Exposes implementation id of a TEE driver in sysfs
>>> to easily spawn corresponding tee-supplicant when device is ready
>>> * Update OP-TEE Message Protocol to better cope with fragmented physical
>>> memory
>>> * Read time directly from OP-TEE driver instead of forwarding the RPC
>>> request to tee-supplicant
>>>
>>> v5:
>>> * Replaced kref reference counting for the device with a size_t instead as
>>> the counter is always protected by a mutex
>>>
>>> v4:
>>> * Rebased on 4.1
>>> * Redesigned the synchronization around entry exit of normal SMC
>>> * Replaced rwsem on the driver instance with kref and completion since
>>> rwsem wasn't intended to be used in this way
>>> * Expanded the TEE_IOCTL_PARAM_ATTR_TYPE_MASK to make room for
>>> future additional parameter types
>>> * Documents TEE subsystem and OP-TEE driver
>>> * Replaced TEE_IOC_CMD with TEE_IOC_OPEN_SESSION, TEE_IOC_INVOKE,
>>> TEE_IOC_CANCEL and TEE_IOC_CLOSE_SESSION
>>> * DT bindings in a separate patch
>>> * Assembly parts moved to arch/arm and arch/arm64 respectively, in a
>>> separate patch
>>> * Redefined/clarified the meaning of OPTEE_SMC_SHM_CACHED
>>> * Removed CMA usage to limit the scope of the patch set
>>>
>>> v3:
>>> * Rebased on 4.1-rc3 (dma_buf_export() API change)
>>> * A couple of small sparse fixes
>>> * Documents bindings for OP-TEE driver
>>> * Updated MAINTAINERS
>>>
>>> v2:
>>> * Replaced the stubbed OP-TEE driver with a real OP-TEE driver
>>> * Removed most APIs not needed by OP-TEE in current state
>>> * Update Documentation/ioctl/ioctl-number.txt with correct path to tee.h
>>> * Rename tee_shm_pool_alloc_cma() to tee_shm_pool_alloc()
>>> * Moved tee.h into include/uapi/linux/
>>> * Redefined tee.h IOCTL macros to be directly based on _IOR and friends
>>> * Removed version info on the API to user space, a data blob which
>>> can contain an UUID is left for user space to be able to tell which
>>> protocol to use in TEE_IOC_CMD
>>> * Changed user space exposed structures to only have types with __ prefix
>>> * Dropped THIS_MODULE from tee_fops
>>> * Reworked how the driver is registered and ref counted:
>>> - moved from using an embedded struct miscdevice to an embedded struct
>>> device.
>>> - uses an struct rw_semaphore as synchronization for driver detachment
>>> - uses alloc/register pattern from TPM
>>>
>>> Thanks,
>>> Jens
>>>
>>> Jens Wiklander (4):
>>> dt/bindings: add bindings for optee
>>> tee: generic TEE subsystem
>>> tee: add OP-TEE driver
>>> Documentation: tee subsystem and op-tee driver
>>>
>>> Documentation/00-INDEX | 2 +
>>> .../bindings/arm/firmware/linaro,optee-tz.txt | 31 +
>>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>>> Documentation/ioctl/ioctl-number.txt | 1 +
>>> Documentation/tee.txt | 118 +++
>>> MAINTAINERS | 13 +
>>> drivers/Kconfig | 2 +
>>> drivers/Makefile | 1 +
>>> drivers/tee/Kconfig | 18 +
>>> drivers/tee/Makefile | 5 +
>>> drivers/tee/optee/Kconfig | 7 +
>>> drivers/tee/optee/Makefile | 5 +
>>> drivers/tee/optee/call.c | 435 ++++++++++
>>> drivers/tee/optee/core.c | 598 ++++++++++++++
>>> drivers/tee/optee/optee_msg.h | 435 ++++++++++
>>> drivers/tee/optee/optee_private.h | 185 +++++
>>> drivers/tee/optee/optee_smc.h | 446 ++++++++++
>>> drivers/tee/optee/rpc.c | 404 +++++++++
>>> drivers/tee/optee/supp.c | 273 +++++++
>>> drivers/tee/tee_core.c | 901 +++++++++++++++++++++
>>> drivers/tee/tee_private.h | 129 +++
>>> drivers/tee/tee_shm.c | 357 ++++++++
>>> drivers/tee/tee_shm_pool.c | 158 ++++
>>> include/linux/tee_drv.h | 278 +++++++
>>> include/uapi/linux/tee.h | 403 +++++++++
>>> 25 files changed, 5206 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
>>> create mode 100644 Documentation/tee.txt
>>> create mode 100644 drivers/tee/Kconfig
>>> create mode 100644 drivers/tee/Makefile
>>> create mode 100644 drivers/tee/optee/Kconfig
>>> create mode 100644 drivers/tee/optee/Makefile
>>> create mode 100644 drivers/tee/optee/call.c
>>> create mode 100644 drivers/tee/optee/core.c
>>> create mode 100644 drivers/tee/optee/optee_msg.h
>>> create mode 100644 drivers/tee/optee/optee_private.h
>>> create mode 100644 drivers/tee/optee/optee_smc.h
>>> create mode 100644 drivers/tee/optee/rpc.c
>>> create mode 100644 drivers/tee/optee/supp.c
>>> create mode 100644 drivers/tee/tee_core.c
>>> create mode 100644 drivers/tee/tee_private.h
>>> create mode 100644 drivers/tee/tee_shm.c
>>> create mode 100644 drivers/tee/tee_shm_pool.c
>>> create mode 100644 include/linux/tee_drv.h
>>> create mode 100644 include/uapi/linux/tee.h
>>>
^ permalink raw reply
* [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Kevin Hilman @ 2016-10-31 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b80010f7-196a-abeb-e4a2-5009f3b7f13b@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> On 10/24/2016 03:03 AM, Linus Walleij wrote:
>> On Fri, Oct 21, 2016 at 4:40 PM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>>> Add support for the Amlogic Meson GXL SoC, this is a partially complete
>>> definition only based on the Amlogic Vendor tree.
>>>
>>> This definition differs a lot from the GXBB and needs a separate entry.
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>
>> Looks good to me. Tell me when I may apply it, it looks orthogonal
>> to the rest of the patches.
>>
>> Yours,
>> Linus Walleij
>>
>
> Hi Linus,
>
> I'm ok to have it applied as soon as possible, but I can send a clean non-rfc patch if needed.
>
Acked-by: Kevin Hilman <khilman@baylibre.com>
I was hoping to have a bit clearer info from the vendor, but based on
vendor BSP, I think we have most of the info, and can do the minor
fixups if/when we get detailed documentation.
Kevin
^ permalink raw reply
* [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver
From: Kevin Hilman @ 2016-10-31 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0d5d1e41-b8e6-5d60-6da1-5b6ddd9bc07e@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> On Monday 31 October 2016 03:24 PM, Bartosz Golaszewski wrote:
>> 2016-10-31 10:52 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
>>> Hi Bartosz,
>>>
>>> On Monday 31 October 2016 03:10 PM, Bartosz Golaszewski wrote:
>>>> 2016-10-31 5:30 GMT+01:00 Rob Herring <robh@kernel.org>:
>>>>> On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
>>>>>> Create the driver for the da8xx master peripheral priority
>>>>>> configuration and implement support for writing to the three
>>>>>> Master Priority registers on da850 SoCs.
>>>>>>
>>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>>>> ---
>>>>>> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
>>>>>> drivers/bus/Kconfig | 9 +
>>>>>> drivers/bus/Makefile | 2 +
>>>>>> drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
>>>>>> 4 files changed, 297 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>>> create mode 100644 drivers/bus/da8xx-mstpri.c
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..225af09
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>>> @@ -0,0 +1,20 @@
>>>>>> +* Device tree bindings for Texas Instruments da8xx master peripheral
>>>>>> + priority driver
>>>>>> +
>>>>>> +DA8XX SoCs feature a set of registers allowing to change the priority of all
>>>>>> +peripherals classified as masters.
>>>>>> +
>>>>>> +Documentation:
>>>>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>>>>>> +
>>>>>> +Required properties:
>>>>>> +
>>>>>> +- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
>>>>>
>>>>> Drop syscon. Doesn't look like it is needed and the example doesn't
>>>>> match.
>>>>
>>>> Hi Rob,
>>>>
>>>> it is needed: syscon_regmap_lookup_by_compatible() fails without it. I
>>>> fixed the example instead.
>>>
>>> Why are master priority registers under syscon? This driver should be
>>> the only entity touching them. So do we need an MFD driver?
>>>
>>
>> It should, but syscfg0 registers are mapped all over the place. I
>
> Not sure what you mean by this. Yes, the sysconfig module has many
> functionalities. But the registers for a given functionality are all
> grouped together AFAICS (except CHIPCFGn, see below).
>
> Pinmux registers are part of syscfg module, but don't use syscon.
>
> In the work going on for OHCI support, chipcfg registers are being put
> under a syscon node. But that makes sense, I think, because chipcfg
> registers are catering to really diverse functionality like PLL and EDMA
> related stuff being placed in the same register - CHIPCFG0.
>
>> thought it would be safer to put them under syscon and Kevin agreed.
>
> Before using syscon for the whole syscfg space, I think we need some
> analysis as to where the likely races are going to be.
I'm OK with that for now. It makes the most sense to use sycon only for
the register (ranges) that will actually be shared.
Kevin
^ permalink raw reply
* [PATCHv2 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: Rob Herring @ 2016-10-31 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <895cf1ec-929a-8c41-c74a-948efcb89222@opensource.altera.com>
On Mon, Oct 31, 2016 at 10:28 AM, Thor Thayer
<tthayer@opensource.altera.com> wrote:
> Hi Rob,
>
> On 10/31/2016 12:36 AM, Rob Herring wrote:
>>
>> On Thu, Oct 27, 2016 at 03:00:23PM -0500, tthayer at opensource.altera.com
>> wrote:
>>>
>>> From: Thor Thayer <tthayer@opensource.altera.com>
>>>
>>> Add the Arria10 DevKit System Resource Chip register and state
>>> monitoring module to the MFD.
>>>
>>> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
>>> ---
>>> Note: This needs to be applied to the bindings document that
>>> was Acked & Applied but didn't reach the for-next branch.
>>> See https://patchwork.ozlabs.org/patch/629397/
>>> ---
>>> v2 Change compatible string -mon to -monitor for clarity
>>> ---
>>> Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>>> b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>>> index ea151f2..c47be28 100644
>>> --- a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>>> +++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>>> @@ -18,6 +18,7 @@ The A10SR consists of these sub-devices:
>>> Device Description
>>> ------ ----------
>>> a10sr_gpio GPIO Controller
>>
>>
>> This should be just "gpio" BTW.
>
>
> I reason I preprend a10sr_ is to distinguish this GPIO from the other GPIOs
> when binding to our LEDs (see below). I think the LEDs need a unique node
> name (unless I'm not understanding something).
You are confusing DTS labels and node names. Labels are global and
just convenience for the DTS source only instead of using full paths
(and can be anything you want). The node name is local to the level it
is at.
> A less important reason I use a10sr_gpio on the node name is that I can cat
> the /sys/class/gpio/gpioxxx/label and see that it is associated with the
> a10sr instead of one of our other general GPIOs. Is there a better way to
> distinguish these?
label should come from the label property I think. This is one of the
problems with the GPIO sysfs interface and why it is being replaced
with the char dev interface.
Rob
>
>>
>>> +a10sr_monitor Register and State Monitoring
>>
>>
>> s/_/-/ or maybe just "monitor". Not really a generic node name to use
>> for this.
>>
>
> The reason I use _ for the node name is that the DTC fails if I reference a
> node name with "-" but works OK for "_". For instance, I get an error if the
> LEDs reference "a10sr-gpio" but "a10sr_gpio" compiles ok.
Again, I'm talking node names. You are talking labels. And yes, DTS
labels can't use '-'.
Rob
^ permalink raw reply
* [PATCH v2] irqchip/bcm2836: Prevent spurious interrupts
From: Thomas Gleixner @ 2016-10-31 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8737jcs8mc.fsf@eliezer.anholt.net>
On Mon, 31 Oct 2016, Eric Anholt wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
>
> > On Fri, 28 Oct 2016, Eric Anholt wrote:
> >
> >> Thomas Gleixner <tglx@linutronix.de> writes:
> >> > This is missing a fixes tag. I have no idea when that problem was
> >> > introduced, so I have no way to decide whether this needs to be tagged
> >> > stable or not.
> >>
> >> This code has been there since introduction of the driver, so:
> >>
> >> Fixes: 1a15aaa998dc ("irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2")
> >
> > So it want's a stable tag, right?
>
> I'm not the author here, and I was just trying to provide an assist with
> upstreaming, so I'm not going to get too involved. I'd say this is an
> edge case for being a stable tree candidate (it's produces a scary dmesg
> warning but no other functional problems that I know of), and I didn't
> add a fixes tag myself because of that.
A fixes tag is not the same as a stable tag, I really want to see Fixes
tags on patches which are bug fixes as it makes it simple to see the
context in which a bug was introduced.
vs. the stable tag: scary warnings tend to confuse users and cause people
to send bug reports. So in this case I'd add one.
Thanks,
tglx
^ permalink raw reply
* [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Bartlomiej Zolnierkiewicz @ 2016-10-31 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031154622.GB1041@n2100.armlinux.org.uk>
Hi,
On Monday, October 31, 2016 03:46:22 PM Russell King - ARM Linux wrote:
> On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote:
> > > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > >
> > > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> > > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > > > This patch disables deprecated IDE subsystem in assabet_defconfig
> > > > > > (no IDE host drivers are selected in this config so there is no
> > > > > > valid reason to enable IDE subsystem itself).
> > > > > >
> > > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > > >
> > > > > I think the series makes a lot of sense. I have checked your assertions
> > > > > in the changelogs and found no flaws in your logic, so I think we should
> > > > > take them all through arm-soc unless there are other concerns.
> > > >
> > > > Thank you.
> > > >
> > > > Should I resend everything or just patches that were not reposted yet
> > > > (the ones that were marked as RFT initially and got no feedback)?
> > >
> > > I'd be fine with just getting a pull request with all the patches that
> > > had no negative feedback and that were not already applied (if any).
> >
> > Here it is (sorry for taking so long).
>
> I've just been digging in the dmesg logs from when I was using the
> Assabet+Neponset as my firewall, and it was having to use the IDE
> ide-cs driver rather than the pata pcmcia driver.
>
> I don't recall whether the pata pcmcia driver was a problem or not,
> as the PCMCIA interface can't cope with _any_ 32-bit accesses. I
> think PATA tries to use the "highest" possible access size by
> default...
It doesn't actually - it defaults to 16-bits for PIO data access and
you must explicitly enable 32-bits using ATA_PFLAG_PIO32 port flag
(pata_pcmcia doesn't set it so it should be okay). Also taskfile
registers are accessed using 8-bits access by default transport
functions (which are used by pata_pcmcia).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Scott Branden @ 2016-10-31 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161029111229.26875-1-zajec5@gmail.com>
Hi Rafal,
On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
>
> Since early BCM5301X days we got abort handler that was removed by
> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise abort
> fault handler"). It assumed we need to deal only with pending aborts
> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>
> When probing PCI config space (device enumeration) it is expected to
> have master aborts on the PCI bus. Most bridges don't forward (or they
> allow disabling it) these errors onto the AXI/AMBA bus but not the
> Northstar (BCM5301X) one.
Should we only add this workaround code if CONFIG_PCI is on then?
>
> iProc PCIe controller on Northstar seems to be some older one, without
> a control register for errors forwarding. It means we need to workaround
> this at platform level. All newer platforms are not affected by this
> issue.
>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
> ---
> arch/arm/mach-bcm/bcm_5301x.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm/mach-bcm/bcm_5301x.c b/arch/arm/mach-bcm/bcm_5301x.c
> index c8830a2..fe067f6 100644
> --- a/arch/arm/mach-bcm/bcm_5301x.c
> +++ b/arch/arm/mach-bcm/bcm_5301x.c
> @@ -9,14 +9,42 @@
> #include <asm/hardware/cache-l2x0.h>
>
> #include <asm/mach/arch.h>
> +#include <asm/siginfo.h>
> +#include <asm/signal.h>
> +
> +#define FSR_EXTERNAL (1 << 12)
> +#define FSR_READ (0 << 10)
> +#define FSR_IMPRECISE 0x0406
>
> static const char *const bcm5301x_dt_compat[] __initconst = {
> "brcm,bcm4708",
> NULL,
> };
>
> +static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
> + struct pt_regs *regs)
> +{
> + /*
> + * We want to ignore aborts forwarded from the PCIe bus that are
> + * expected and shouldn't really be passed by the PCIe controller.
> + * The biggest disadvantage is the same FSR code may be reported when
> + * reading non-existing APB register and we shouldn't ignore that.
> + */
> + if (fsr == (FSR_EXTERNAL | FSR_READ | FSR_IMPRECISE))
> + return 0;
> +
> + return 1;
> +}
> +
> +static void __init bcm5301x_init_early(void)
> +{
> + hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, BUS_OBJERR,
> + "imprecise external abort");
> +}
> +
> DT_MACHINE_START(BCM5301X, "BCM5301X")
> .l2c_aux_val = 0,
> .l2c_aux_mask = ~0,
> .dt_compat = bcm5301x_dt_compat,
> + .init_early = bcm5301x_init_early,
> MACHINE_END
>
Regards,
Scott
^ permalink raw reply
* [PATCH v14 1/4] clk: mediatek: Add MT2701 clock support
From: Stephen Boyd @ 2016-10-31 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477896558.5376.13.camel@mtksdaap41>
On 10/31, James Liao wrote:
> On Thu, 2016-10-27 at 18:17 -0700, Stephen Boyd wrote:
> > On 10/21, Erin Lo wrote:
> > > @@ -244,3 +256,31 @@ void mtk_clk_register_composites(const struct mtk_composite *mcs,
> > > clk_data->clks[mc->id] = clk;
> > > }
> > > }
> > > +
> > > +void mtk_clk_register_dividers(const struct mtk_clk_divider *mcds,
> > > + int num, void __iomem *base, spinlock_t *lock,
> > > + struct clk_onecell_data *clk_data)
> > > +{
> > > + struct clk *clk;
> > > + int i;
> > > +
> > > + for (i = 0; i < num; i++) {
> > > + const struct mtk_clk_divider *mcd = &mcds[i];
> > > +
> > > + if (clk_data && !IS_ERR_OR_NULL(clk_data->clks[mcd->id]))
> >
> > NULL is a valid clk. IS_ERR_OR_NULL is usually wrong.
>
> Why NULL is a valid clk?
Perhaps at some point we'll want to return a NULL pointer to
clk_get() callers so that they can handle things like optional
clocks easily without having any storage requirements. I don't
know if we'll ever do that, but that's just a possibility.
>
> clk_data is designed for multiple initialization from different clock
> types, such as infra_clk_data in clk-mt2701.c. So it will ignore valid
> clocks to avoid duplicated clock registration. Here I assume a clock
> pointer with error code or NULL to be an invalid (not initialized)
> clock.
>
Ok. Would it be possible to initialize the array with all error
pointers? That would make things less error prone, but it
probably doesn't matter at all anyway because this is done during
registration time. IS_ERR_OR_NULL makes me take a second look
each time, because it's usually wrong.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V2 2/2] ARM: dts: bcm283x: fix typo in mailbox address
From: Eric Anholt @ 2016-10-31 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477848139-32267-1-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> The address of the mailbox node in the bcm283x.dtsi also has a typo.
> So fix it accordingly.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Reviewed-by: Andreas F?rber <afaerber@suse.de>
> Fixes: 05b682b7a3b2 ("ARM: bcm2835: dt: Add the mailbox to the device tree")
Pulled to bcm2835-dt-next. Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/becdf39e/attachment.sig>
^ permalink raw reply
* [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Stefan Wahren @ 2016-10-31 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877f8os8vo.fsf@eliezer.anholt.net>
> Eric Anholt <eric@anholt.net> hat am 31. Oktober 2016 um 18:53 geschrieben:
>
>
> Stefan Wahren <stefan.wahren@i2se.com> writes:
>
> > Hi Eric,
> >
> >> Eric Anholt <eric@anholt.net> hat am 27. Oktober 2016 um 18:52 geschrieben:
> >>
> >>
> >> From: Linus Walleij <linus.walleij@linaro.org>
> >>
> >> The idea is to give useful names to GPIO lines that an implementer
> >> will be using from userspace, e.g. for maker type projects. These are
> >> user-visible using tools/gpio/lsgpio.c
> >
> > sorry for the late feedback, but did you check your patch against the
> > Firmware
> > DTS [1]?
> >
> > As an example the GPIO38 is connected and named as USB_LIMIT_1A2 since
> > Raspberry
> > Pi 1 B Plus.
> >
> > [1] -
> > https://github.com/raspberrypi/documentation/blob/master/configuration/images/dt-blob.dts
>
> I did use the dt-blob sometimes for cross-checking, but these are
> written against the schematics, not the dt-blob. If you've got things
> you'd like changed, could you send a patch?
A patch against your v3 or my own v4 based on your patch?
^ permalink raw reply
* [PATCH v2] irqchip/bcm2836: Prevent spurious interrupts
From: Eric Anholt @ 2016-10-31 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1610282141030.5053@nanos>
Thomas Gleixner <tglx@linutronix.de> writes:
> On Fri, 28 Oct 2016, Eric Anholt wrote:
>
>> Thomas Gleixner <tglx@linutronix.de> writes:
>> > This is missing a fixes tag. I have no idea when that problem was
>> > introduced, so I have no way to decide whether this needs to be tagged
>> > stable or not.
>>
>> This code has been there since introduction of the driver, so:
>>
>> Fixes: 1a15aaa998dc ("irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2")
>
> So it want's a stable tag, right?
I'm not the author here, and I was just trying to provide an assist with
upstreaming, so I'm not going to get too involved. I'd say this is an
edge case for being a stable tree candidate (it's produces a scary dmesg
warning but no other functional problems that I know of), and I didn't
add a fixes tag myself because of that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/9eb0eb34/attachment.sig>
^ permalink raw reply
* [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Eric Anholt @ 2016-10-31 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2009597620.98560.11cdcb7c-b46d-43f0-a853-b742fde3546a.open-xchange@email.1und1.de>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> Hi Eric,
>
>> Eric Anholt <eric@anholt.net> hat am 27. Oktober 2016 um 18:52 geschrieben:
>>
>>
>> From: Linus Walleij <linus.walleij@linaro.org>
>>
>> The idea is to give useful names to GPIO lines that an implementer
>> will be using from userspace, e.g. for maker type projects. These are
>> user-visible using tools/gpio/lsgpio.c
>
> sorry for the late feedback, but did you check your patch against the Firmware
> DTS [1]?
>
> As an example the GPIO38 is connected and named as USB_LIMIT_1A2 since Raspberry
> Pi 1 B Plus.
>
> [1] -
> https://github.com/raspberrypi/documentation/blob/master/configuration/images/dt-blob.dts
I did use the dt-blob sometimes for cross-checking, but these are
written against the schematics, not the dt-blob. If you've got things
you'd like changed, could you send a patch?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/f5aa89db/attachment.sig>
^ permalink raw reply
* [PATCH v2] KVM: arm/arm64: vgic: Prevent access to invalid SPIs
From: Andre Przywara @ 2016-10-31 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In our VGIC implementation we limit the number of SPIs to a number
that the userland application told us. Accordingly we limit the
allocation of memory for virtual IRQs to that number.
However in our MMIO dispatcher we didn't check if we ever access an
IRQ beyond that limit, leading to out-of-bound accesses.
Add a test against the number of allocated SPIs in check_region().
Adjust the VGIC_ADDR_TO_INTID macro to avoid an actual division, which
is not implemented on ARM(32).
[maz: cleaned-up original patch]
Cc: stable at vger.kernel.org
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
Hi Marc,
does the last hunk fix the GCC issue that your recent fix addresses
as well? ilog2 seems to be pretty cheap on ARM and ARM64, so I wonder
if this version of the fix is better, since smaller?
Cheers,
Andre.
Changes v1 .. v2:
- fix compilation for 32-bit ARM
virt/kvm/arm/vgic/vgic-mmio.c | 41 +++++++++++++++++++++++++++--------------
virt/kvm/arm/vgic/vgic-mmio.h | 2 +-
2 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
index e18b30d..ebe1b9f 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.c
+++ b/virt/kvm/arm/vgic/vgic-mmio.c
@@ -453,17 +453,33 @@ struct vgic_io_device *kvm_to_vgic_iodev(const struct kvm_io_device *dev)
return container_of(dev, struct vgic_io_device, dev);
}
-static bool check_region(const struct vgic_register_region *region,
+static bool check_region(const struct kvm *kvm,
+ const struct vgic_register_region *region,
gpa_t addr, int len)
{
- if ((region->access_flags & VGIC_ACCESS_8bit) && len == 1)
- return true;
- if ((region->access_flags & VGIC_ACCESS_32bit) &&
- len == sizeof(u32) && !(addr & 3))
- return true;
- if ((region->access_flags & VGIC_ACCESS_64bit) &&
- len == sizeof(u64) && !(addr & 7))
- return true;
+ int flags, nr_irqs = kvm->arch.vgic.nr_spis + VGIC_NR_PRIVATE_IRQS;
+
+ switch (len) {
+ case sizeof(u8):
+ flags = VGIC_ACCESS_8bit;
+ break;
+ case sizeof(u32):
+ flags = VGIC_ACCESS_32bit;
+ break;
+ case sizeof(u64):
+ flags = VGIC_ACCESS_64bit;
+ break;
+ default:
+ return false;
+ }
+
+ if ((region->access_flags & flags) && IS_ALIGNED(addr, len)) {
+ if (!region->bits_per_irq)
+ return true;
+
+ /* Do we access a non-allocated IRQ? */
+ return VGIC_ADDR_TO_INTID(addr, region->bits_per_irq) < nr_irqs;
+ }
return false;
}
@@ -477,7 +493,7 @@ static int dispatch_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
addr - iodev->base_addr);
- if (!region || !check_region(region, addr, len)) {
+ if (!region || !check_region(vcpu->kvm, region, addr, len)) {
memset(val, 0, len);
return 0;
}
@@ -510,10 +526,7 @@ static int dispatch_mmio_write(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
addr - iodev->base_addr);
- if (!region)
- return 0;
-
- if (!check_region(region, addr, len))
+ if (!region || !check_region(vcpu->kvm, region, addr, len))
return 0;
switch (iodev->iodev_type) {
diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
index 4c34d39..dacd1155 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.h
+++ b/virt/kvm/arm/vgic/vgic-mmio.h
@@ -58,7 +58,7 @@ extern struct kvm_io_device_ops kvm_io_gic_ops;
* numerator and denominator with 8 to support at most 64 bits per IRQ:
*/
#define VGIC_ADDR_TO_INTID(addr, bits) (((addr) & VGIC_ADDR_IRQ_MASK(bits)) * \
- 64 / (bits) / 8)
+ 64 >> (ilog2(bits) + 3))
/*
* Some VGIC registers store per-IRQ information, with a different number
--
2.9.0
^ permalink raw reply related
* [RFC PATCH v2 5/5] ARM64: dts: meson-gxl-s905x: Enable internal ethernet PHY
From: Neil Armstrong @ 2016-10-31 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477932987-27871-1-git-send-email-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
index 07f0e0b..08237ee 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
@@ -46,3 +46,9 @@
/ {
compatible = "amlogic,s905x", "amlogic,meson-gxl";
};
+
+/* S905X Only has access to its internal PHY */
+ðmac {
+ phy-mode = "rmii";
+ phy-handle = <&internal_phy>;
+};
--
1.9.1
^ permalink raw reply related
* [RFC PATCH v2 4/5] ARM64: dts: meson-gxl-p23x: Enable ethernet
From: Neil Armstrong @ 2016-10-31 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477932987-27871-1-git-send-email-narmstrong@baylibre.com>
Enable Ethernet on the p23x board, pinctrl attribute is only added for
the p230 board since the p231 only uses the Internal PHY.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi | 4 ++++
3 files changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index 3dfaa37..a569286 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -49,3 +49,19 @@
compatible = "amlogic,p230", "amlogic,s905d", "amlogic,meson-gxl";
model = "Amlogic Meson GXL (S905D) P230 Development Board";
};
+
+/* P230 has exclusive choice between internal or external PHY */
+ðmac {
+ pinctrl-0 = <ð_pins>;
+ pinctrl-names = "default";
+
+ phy-handle = <&external_phy>;
+};
+
+&external_mdio {
+ external_phy: ethernet-phy at 0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ max-speed = <1000>;
+ };
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
index ade8d29..1cc8d49 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
@@ -49,3 +49,9 @@
compatible = "amlogic,p231", "amlogic,s905d", "amlogic,meson-gxl";
model = "Amlogic Meson GXL (S905D) P231 Development Board";
};
+
+/* P231 has only internal PHY port */
+ðmac {
+ phy-mode = "rmii";
+ phy-handle = <&internal_phy>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi
index bbe46a2..622ffbe 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi
@@ -182,3 +182,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+ðmac {
+ status = "okay";
+};
--
1.9.1
^ permalink raw reply related
* [RFC PATCH v2 3/5] ARM64: dts: meson-gxl: Add ethernet nodes with internal PHY
From: Neil Armstrong @ 2016-10-31 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477932987-27871-1-git-send-email-narmstrong@baylibre.com>
Add Ethernet node with Internal PHY selection for the Amlogic GXL SoCs
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 45 ++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index d1bf381..71670c3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -47,6 +47,24 @@
/ {
compatible = "amlogic,meson-gxl";
+
+
+};
+
+ðmac {
+ reg = <0x0 0xc9410000 0x0 0x10000
+ 0x0 0xc8834540 0x0 0x4>;
+
+ clocks = <&clkc CLKID_ETH>,
+ <&clkc CLKID_FCLK_DIV2>,
+ <&clkc CLKID_MPLL2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+
+ mdio0: mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ };
};
&aobus {
@@ -214,6 +232,33 @@
};
};
};
+
+ eth-phy-mux {
+ compatible = "mdio-mux-mmioreg", "mdio-mux";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x55c 0x0 0x4>;
+ mux-mask = <0xffffffff>;
+ mdio-parent-bus = <&mdio0>;
+
+ internal_mdio: mdio at e40908ff {
+ reg = <0xe40908ff>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ internal_phy: ethernet-phy at 8 {
+ compatible = "ethernet-phy-id0181.4400", "ethernet-phy-ieee802.3-c22";
+ reg = <8>;
+ max-speed = <100>;
+ };
+ };
+
+ external_mdio: mdio at 2009087f {
+ reg = <0x2009087f>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
};
&hiubus {
--
1.9.1
^ permalink raw reply related
* [RFC PATCH v2 2/5] net: phy: Add Meson GXL Internal PHY driver
From: Neil Armstrong @ 2016-10-31 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477932987-27871-1-git-send-email-narmstrong@baylibre.com>
Add driver for the Internal RMII PHY found in the Amlogic Meson GXL SoCs.
This PHY seems to only implement some standard registers and need some
workarounds to provide autoneg values from vendor registers.
Some magic values are currently used to configure the PHY, and this a
temporary setup until clarification about these registers names and
registers fields are provided by Amlogic.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/net/phy/Kconfig | 5 +++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/meson-gxl.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 87 insertions(+)
create mode 100644 drivers/net/phy/meson-gxl.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 2651c8d..09342b6 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -226,6 +226,11 @@ config DP83867_PHY
---help---
Currently supports the DP83867 PHY.
+config MESON_GXL_PHY
+ tristate "Amlogic Meson GXL Internal PHY"
+ ---help---
+ Currently has a driver for the Amlogic Meson GXL Internal PHY
+
config FIXED_PHY
tristate "MDIO Bus/PHY emulation with fixed speed/link PHYs"
depends on PHYLIB
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e58667d..1511b3e 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_MARVELL_PHY) += marvell.o
obj-$(CONFIG_MICREL_KS8995MA) += spi_ks8995.o
obj-$(CONFIG_MICREL_PHY) += micrel.o
obj-$(CONFIG_MICROCHIP_PHY) += microchip.o
+obj-$(CONFIG_MESON_GXL_PHY) += meson-gxl.o
obj-$(CONFIG_MICROSEMI_PHY) += mscc.o
obj-$(CONFIG_NATIONAL_PHY) += national.o
obj-$(CONFIG_QSEMI_PHY) += qsemi.o
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
new file mode 100644
index 0000000..1ea69b7
--- /dev/null
+++ b/drivers/net/phy/meson-gxl.c
@@ -0,0 +1,81 @@
+/*
+ * Amlogic Meson GXL Internal PHY Driver
+ *
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ * Copyright (C) 2016 BayLibre, SAS. All rights reserved.
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mii.h>
+#include <linux/ethtool.h>
+#include <linux/phy.h>
+#include <linux/netdevice.h>
+
+static int meson_gxl_config_init(struct phy_device *phydev)
+{
+ /* Enable Analog and DSP register Bank access by */
+ phy_write(phydev, 0x14, 0x0000);
+ phy_write(phydev, 0x14, 0x0400);
+ phy_write(phydev, 0x14, 0x0000);
+ phy_write(phydev, 0x14, 0x0400);
+
+ /* Write Analog register 23 */
+ phy_write(phydev, 0x17, 0x8E0D);
+ phy_write(phydev, 0x14, 0x4417);
+
+ /* Enable fractional PLL */
+ phy_write(phydev, 0x17, 0x0005);
+ phy_write(phydev, 0x14, 0x5C1B);
+
+ /* Program fraction FR_PLL_DIV1 */
+ phy_write(phydev, 0x17, 0x029A);
+ phy_write(phydev, 0x14, 0x5C1D);
+
+ /* Program fraction FR_PLL_DIV1 */
+ phy_write(phydev, 0x17, 0xAAAA);
+ phy_write(phydev, 0x14, 0x5C1C);
+
+ return 0;
+}
+
+static struct phy_driver meson_gxl_phy[] = {
+ {
+ .phy_id = 0x01814400,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Meson GXL Internal PHY",
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_IS_INTERNAL,
+ .config_init = meson_gxl_config_init,
+ .config_aneg = genphy_config_aneg,
+ .aneg_done = genphy_aneg_done,
+ .read_status = genphy_read_status,
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ },
+};
+
+static struct mdio_device_id __maybe_unused meson_gxl_tbl[] = {
+ { 0x01814400, 0xfffffff0 },
+ { }
+};
+
+module_phy_driver(meson_gxl_phy);
+
+MODULE_DEVICE_TABLE(mdio, meson_gxl_tbl);
+
+MODULE_DESCRIPTION("Amlogic Meson GXL Internal PHY driver");
+MODULE_AUTHOR("Baoqi wang");
+MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [RFC PATCH v2 1/5] net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
From: Neil Armstrong @ 2016-10-31 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477932987-27871-1-git-send-email-narmstrong@baylibre.com>
In order to support PHY switching on Amlogic GXL SoCs, add support for
16bit and 32bit registers sizes.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/net/mdio-mux-mmioreg.txt | 4 +-
drivers/net/phy/mdio-mux-mmioreg.c | 60 +++++++++++++++++-----
2 files changed, 49 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
index 8516929..065e8bd 100644
--- a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
+++ b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
@@ -3,7 +3,7 @@ Properties for an MDIO bus multiplexer controlled by a memory-mapped device
This is a special case of a MDIO bus multiplexer. A memory-mapped device,
like an FPGA, is used to control which child bus is connected. The mdio-mux
node must be a child of the memory-mapped device. The driver currently only
-supports devices with eight-bit registers.
+supports devices with 8, 16 or 32-bit registers.
Required properties in addition to the generic multiplexer properties:
@@ -11,7 +11,7 @@ Required properties in addition to the generic multiplexer properties:
- reg : integer, contains the offset of the register that controls the bus
multiplexer. The size field in the 'reg' property is the size of
- register, and must therefore be 1.
+ register, and must therefore be 1, 2, or 4.
- mux-mask : integer, contains an eight-bit mask that specifies which
bits in the register control the actual bus multiplexer. The
diff --git a/drivers/net/phy/mdio-mux-mmioreg.c b/drivers/net/phy/mdio-mux-mmioreg.c
index d0bed52..6a33646 100644
--- a/drivers/net/phy/mdio-mux-mmioreg.c
+++ b/drivers/net/phy/mdio-mux-mmioreg.c
@@ -21,7 +21,8 @@
struct mdio_mux_mmioreg_state {
void *mux_handle;
phys_addr_t phys;
- uint8_t mask;
+ unsigned int iosize;
+ unsigned int mask;
};
/*
@@ -47,17 +48,47 @@ static int mdio_mux_mmioreg_switch_fn(int current_child, int desired_child,
struct mdio_mux_mmioreg_state *s = data;
if (current_child ^ desired_child) {
- void __iomem *p = ioremap(s->phys, 1);
- uint8_t x, y;
-
+ void __iomem *p = ioremap(s->phys, s->iosize);
if (!p)
return -ENOMEM;
- x = ioread8(p);
- y = (x & ~s->mask) | desired_child;
- if (x != y) {
- iowrite8((x & ~s->mask) | desired_child, p);
- pr_debug("%s: %02x -> %02x\n", __func__, x, y);
+ switch (s->iosize) {
+ case sizeof(uint8_t): {
+ uint8_t x, y;
+
+ x = ioread8(p);
+ y = (x & ~s->mask) | desired_child;
+ if (x != y) {
+ iowrite8((x & ~s->mask) | desired_child, p);
+ pr_debug("%s: %02x -> %02x\n", __func__, x, y);
+ }
+
+ break;
+ }
+ case sizeof(uint16_t): {
+ uint16_t x, y;
+
+ x = ioread16(p);
+ y = (x & ~s->mask) | desired_child;
+ if (x != y) {
+ iowrite16((x & ~s->mask) | desired_child, p);
+ pr_debug("%s: %04x -> %04x\n", __func__, x, y);
+ }
+
+ break;
+ }
+ case sizeof(uint32_t): {
+ uint32_t x, y;
+
+ x = ioread32(p);
+ y = (x & ~s->mask) | desired_child;
+ if (x != y) {
+ iowrite32((x & ~s->mask) | desired_child, p);
+ pr_debug("%s: %08x -> %08x\n", __func__, x, y);
+ }
+
+ break;
+ }
}
iounmap(p);
@@ -88,8 +119,11 @@ static int mdio_mux_mmioreg_probe(struct platform_device *pdev)
}
s->phys = res.start;
- if (resource_size(&res) != sizeof(uint8_t)) {
- dev_err(&pdev->dev, "only 8-bit registers are supported\n");
+ s->iosize = resource_size(&res);
+ if (s->iosize != sizeof(uint8_t) &&
+ s->iosize != sizeof(uint16_t) &&
+ s->iosize != sizeof(uint32_t)) {
+ dev_err(&pdev->dev, "only 8/16/32-bit registers are supported\n");
return -EINVAL;
}
@@ -98,8 +132,8 @@ static int mdio_mux_mmioreg_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "missing or invalid mux-mask property\n");
return -ENODEV;
}
- if (be32_to_cpup(iprop) > 255) {
- dev_err(&pdev->dev, "only 8-bit registers are supported\n");
+ if (be32_to_cpup(iprop) >= BIT(s->iosize * 8)) {
+ dev_err(&pdev->dev, "only 8/16/32-bit registers are supported\n");
return -EINVAL;
}
s->mask = be32_to_cpup(iprop);
--
1.9.1
^ permalink raw reply related
* [RFC PATCH v2 0/5] ARM64: Add Internal PHY support for Meson GXL
From: Neil Armstrong @ 2016-10-31 16:56 UTC (permalink / raw)
To: linux-arm-kernel
The Amlogic Meson GXL SoCs have an internal RMII PHY that is muxed with the
external RGMII pins.
In order to support switching between the two PHYs links, extended registers
size for mdio-mux-mmioreg must be added.
Finally, the internal PHY is added in the GXL dtsi and support for each
board is added in intermediate board family dtsi or final dts.
This patchset depends on ARM64 dts patch at [1]
Changes since original RFC patchset at : [2]
- Remove meson8b experimental phy switching
- Switch to mdio-mux-mmioreg with extennded size support
- Add internal phy support for S905x and p231
- Add external PHY support for p230
[1] http://lkml.kernel.org/r/1477932286-27482-1-git-send-email-narmstrong at baylibre.com
[2] http://lkml.kernel.org/r/1477060838-14164-1-git-send-email-narmstrong at baylibre.com
Neil Armstrong (5):
net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
net: phy: Add Meson GXL Internal PHY driver
ARM64: dts: meson-gxl: Add ethernet nodes with internal PHY
ARM64: dts: meson-gxl-p23x: Enable ethernet
ARM64: dts: meson-gxl-s905x: Enable internal ethernet PHY
.../devicetree/bindings/net/mdio-mux-mmioreg.txt | 4 +-
.../boot/dts/amlogic/meson-gxl-s905d-p230.dts | 16 +++++
.../boot/dts/amlogic/meson-gxl-s905d-p231.dts | 6 ++
.../boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi | 4 ++
arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi | 6 ++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 45 ++++++++++++
drivers/net/phy/Kconfig | 5 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-mux-mmioreg.c | 60 ++++++++++++----
drivers/net/phy/meson-gxl.c | 81 ++++++++++++++++++++++
10 files changed, 213 insertions(+), 15 deletions(-)
create mode 100644 drivers/net/phy/meson-gxl.c
--
1.9.1
^ permalink raw reply
* [PATCH 8/8] ARM64: dts: meson-gxl-p23x: Enable IR receiver
From: Neil Armstrong @ 2016-10-31 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477932286-27482-1-git-send-email-narmstrong@baylibre.com>
Enable the Infraread Receiver on the p23x board.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi
index 7830809..bbe46a2 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi
@@ -105,6 +105,12 @@
pinctrl-names = "default";
};
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_input_ao_pins>;
+ pinctrl-names = "default";
+};
+
/* Wireless SDIO Module */
&sd_emmc_a {
status = "okay";
--
1.9.1
^ permalink raw reply related
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