On Wed, Sep 30, 2020 at 09:32:20AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 08:44, Nicolin Chen пишет:
> > On Wed, Sep 30, 2020 at 08:12:10AM +0300, Dmitry Osipenko wrote:
> >> 30.09.2020 03:30, Nicolin Chen пишет:
> >> ...
> >>> int tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigne
On Tue, Sep 29 2020 at 16:03, Megha Dey wrote:
> On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
>> #9 is obviously just for the folks interested in IMS
>>
>
> I see that the tip tree (as of 9/29) has most of these patches but
> notice that the DEV_MSI related patches
>
> haven't made it. I have te
On Wed, Sep 30, 2020 at 08:20:50AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 08:10, Dmitry Osipenko пишет:
> > 30.09.2020 03:30, Nicolin Chen пишет:
> >> static void tegra_smmu_release_device(struct device *dev)
> >
> > The tegra_get_memory_controller() uses of_find_device_by_node(), hence
> > t
30.09.2020 09:13, Nicolin Chen пишет:
> On Wed, Sep 30, 2020 at 09:10:38AM +0300, Dmitry Osipenko wrote:
>> 30.09.2020 08:49, Nicolin Chen пишет:
>>> On Wed, Sep 30, 2020 at 08:11:52AM +0300, Dmitry Osipenko wrote:
30.09.2020 03:30, Nicolin Chen пишет:
> + /* An invalid mc pointer means mc
30.09.2020 08:44, Nicolin Chen пишет:
> On Wed, Sep 30, 2020 at 08:12:10AM +0300, Dmitry Osipenko wrote:
>> 30.09.2020 03:30, Nicolin Chen пишет:
>> ...
>>> int tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigned long
>>> rate);
>>> unsigned int tegra_mc_get_emem_device_count(struct
On Wed, Sep 30, 2020 at 08:59:45AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 08:41, Nicolin Chen пишет:
> > On Wed, Sep 30, 2020 at 08:39:54AM +0300, Dmitry Osipenko wrote:
> >> 30.09.2020 03:30, Nicolin Chen пишет:
> >>> static int tegra_smmu_attach_dev(struct iommu_domain *domain,
> >>>
On Wed, Sep 30, 2020 at 09:10:38AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 08:49, Nicolin Chen пишет:
> > On Wed, Sep 30, 2020 at 08:11:52AM +0300, Dmitry Osipenko wrote:
> >> 30.09.2020 03:30, Nicolin Chen пишет:
> >>> + /* An invalid mc pointer means mc and smmu drivers are not ready */
> >>>
30.09.2020 08:49, Nicolin Chen пишет:
> On Wed, Sep 30, 2020 at 08:11:52AM +0300, Dmitry Osipenko wrote:
>> 30.09.2020 03:30, Nicolin Chen пишет:
>>> + /* An invalid mc pointer means mc and smmu drivers are not ready */
>>> + if (IS_ERR_OR_NULL(mc))
>>
>> tegra_get_memory_controller() doesn't r
30.09.2020 08:34, Nicolin Chen пишет:
> On Wed, Sep 30, 2020 at 08:10:35AM +0300, Dmitry Osipenko wrote:
>> 30.09.2020 03:30, Nicolin Chen пишет:
>>> void tegra_smmu_remove(struct tegra_smmu *smmu)
>>> {
>>> + bus_set_iommu(&platform_bus_type, NULL);
>>
>> Why only platform_bus? Is this really
On 9/28/2020 6:11 PM, Vijayanand Jitta wrote:
>
>
> On 9/18/2020 8:11 PM, Robin Murphy wrote:
>> On 2020-08-20 13:49, vji...@codeaurora.org wrote:
>>> From: Vijayanand Jitta
>>>
>>> When ever an iova alloc request fails we free the iova
>>> ranges present in the percpu iova rcaches and then re
30.09.2020 08:41, Nicolin Chen пишет:
> On Wed, Sep 30, 2020 at 08:39:54AM +0300, Dmitry Osipenko wrote:
>> 30.09.2020 03:30, Nicolin Chen пишет:
>>> static int tegra_smmu_attach_dev(struct iommu_domain *domain,
>>> struct device *dev)
>>> {
>>> + struct iommu_fwspe
30.09.2020 08:29, Nicolin Chen пишет:
> Hi Dmitry,
>
> On Wed, Sep 30, 2020 at 08:10:07AM +0300, Dmitry Osipenko wrote:
>> 30.09.2020 03:30, Nicolin Chen пишет:
>>> - group->group = iommu_group_alloc();
>>> + group->group = pci ? pci_device_group(dev) : iommu_group_alloc();
>>
>> This will be
On Wed, Sep 30, 2020 at 08:20:50AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 08:10, Dmitry Osipenko пишет:
> > 30.09.2020 03:30, Nicolin Chen пишет:
> >> static void tegra_smmu_release_device(struct device *dev)
> >
> > The tegra_get_memory_controller() uses of_find_device_by_node(), hence
> > t
On Wed, Sep 30, 2020 at 08:11:52AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> > + /* An invalid mc pointer means mc and smmu drivers are not ready */
> > + if (IS_ERR_OR_NULL(mc))
>
> tegra_get_memory_controller() doesn't return NULL.
Well, I don't want to assume
On Wed, Sep 30, 2020 at 08:12:10AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> ...
> > int tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigned long
> > rate);
> > unsigned int tegra_mc_get_emem_device_count(struct tegra_mc *mc);
> > +struct tegra_mc *tegra
30.09.2020 08:39, Nicolin Chen пишет:
> On Wed, Sep 30, 2020 at 08:24:02AM +0300, Dmitry Osipenko wrote:
>> 30.09.2020 03:30, Nicolin Chen пишет:
>>> + /*
>>> +* IOMMU core allows -ENODEV return to carry on. So bypass any call
>>> +* from bus_set_iommu() during tegra_smmu_probe(), as a de
From: Vijayanand Jitta
When ever a new iova alloc request comes iova is always searched
from the cached node and the nodes which are previous to cached
node. So, even if there is free iova space available in the nodes
which are next to the cached node iova allocation can still fail
because of thi
On 9/18/2020 7:48 PM, Robin Murphy wrote:
> On 2020-08-20 13:49, vji...@codeaurora.org wrote:
>> From: Vijayanand Jitta
>>
>> When ever a new iova alloc request comes iova is always searched
>> from the cached node and the nodes which are previous to cached
>> node. So, even if there is free iov
From: Vijayanand Jitta
When ever an iova alloc request fails we free the iova
ranges present in the percpu iova rcaches and then retry
but the global iova rcache is not freed as a result we could
still see iova alloc failure even after retry as global
rcache is holding the iova's which can cause
On Wed, Sep 30, 2020 at 08:39:54AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> > static int tegra_smmu_attach_dev(struct iommu_domain *domain,
> > struct device *dev)
> > {
> > + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>
On Wed, Sep 30, 2020 at 08:24:02AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> > + /*
> > +* IOMMU core allows -ENODEV return to carry on. So bypass any call
> > +* from bus_set_iommu() during tegra_smmu_probe(), as a device will
> > +* call in again via of
30.09.2020 03:30, Nicolin Chen пишет:
> static int tegra_smmu_attach_dev(struct iommu_domain *domain,
>struct device *dev)
> {
> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
> struct
On Wed, Sep 30, 2020 at 08:10:35AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> > void tegra_smmu_remove(struct tegra_smmu *smmu)
> > {
> > + bus_set_iommu(&platform_bus_type, NULL);
>
> Why only platform_bus? Is this really needed at all?
I see qcom_iommu.c file se
Hi Dmitry,
On Wed, Sep 30, 2020 at 08:10:07AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> > - group->group = iommu_group_alloc();
> > + group->group = pci ? pci_device_group(dev) : iommu_group_alloc();
>
> This will be nicer to write as:
>
> if (dev_is_pci(dev))
>
On Wed, Sep 30, 2020 at 08:10:00AM +0300, Dmitry Osipenko wrote:
> 30.09.2020 03:30, Nicolin Chen пишет:
> ...
> > +#ifdef CONFIG_PCI
> > + if (!iommu_present(&pci_bus_type)) {
>
> Could you please explain why this check is needed?
That's referencing what's in the arm-smmu.c file, since it does
30.09.2020 03:30, Nicolin Chen пишет:
> + /*
> + * IOMMU core allows -ENODEV return to carry on. So bypass any call
> + * from bus_set_iommu() during tegra_smmu_probe(), as a device will
> + * call in again via of_iommu_configure when fwspec is prepared.
> + */
> + if (!
30.09.2020 08:10, Dmitry Osipenko пишет:
> 30.09.2020 03:30, Nicolin Chen пишет:
>> static void tegra_smmu_release_device(struct device *dev)
>
> The tegra_get_memory_controller() uses of_find_device_by_node(), hence
> tegra_smmu_release_device() should put_device(mc) in order to balance
> back t
30.09.2020 03:30, Nicolin Chen пишет:
...
> int tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigned long
> rate);
> unsigned int tegra_mc_get_emem_device_count(struct tegra_mc *mc);
> +struct tegra_mc *tegra_get_memory_controller(void);
>
> #endif /* __SOC_TEGRA_MC_H__ */
>
This
30.09.2020 03:30, Nicolin Chen пишет:
> + /* An invalid mc pointer means mc and smmu drivers are not ready */
> + if (IS_ERR_OR_NULL(mc))
tegra_get_memory_controller() doesn't return NULL.
> + return ERR_PTR(-EPROBE_DEFER);
___
iomm
30.09.2020 03:30, Nicolin Chen пишет:
> void tegra_smmu_remove(struct tegra_smmu *smmu)
> {
> + bus_set_iommu(&platform_bus_type, NULL);
Why only platform_bus? Is this really needed at all?
> iommu_device_unregister(&smmu->iommu);
> iommu_device_sysfs_remove(&smmu->iommu);
30.09.2020 03:30, Nicolin Chen пишет:
...
> +#ifdef CONFIG_PCI
> + if (!iommu_present(&pci_bus_type)) {
Could you please explain why this check is needed?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailm
30.09.2020 03:30, Nicolin Chen пишет:
> static void tegra_smmu_release_device(struct device *dev)
The tegra_get_memory_controller() uses of_find_device_by_node(), hence
tegra_smmu_release_device() should put_device(mc) in order to balance
back the refcounting.
30.09.2020 03:30, Nicolin Chen пишет:
> - group->group = iommu_group_alloc();
> + group->group = pci ? pci_device_group(dev) : iommu_group_alloc();
This will be nicer to write as:
if (dev_is_pci(dev))
group->group = pci_device_group(dev);
else
group->group = generic_device_group(d
On Wed, Sep 30, 2020 at 06:19:57AM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 29, 2020 at 07:47:52PM -0400, Daniel P. Smith wrote:
> > TrenchBoot's AMD Secure Loader (LZ). The former is not well supported
> > and the latter will be getting maintenance under TB. While this is not
> > preferred, we
On Tue, Sep 29, 2020 at 07:47:52PM -0400, Daniel P. Smith wrote:
> TrenchBoot's AMD Secure Loader (LZ). The former is not well supported
> and the latter will be getting maintenance under TB. While this is not
> preferred, we had to weigh this versus trying to convince you and the
> other TPM drive
On Tue, Sep 29, 2020 at 08:42:52PM +0300, Dmitry Osipenko wrote:
> 29.09.2020 09:13, Nicolin Chen пишет:
> > This is used to protect potential race condition at use_count.
> > since probes of client drivers, calling attach_dev(), may run
> > concurrently.
> >
> > Signed-off-by: Nicolin Chen
> > -
This series is to add PCI support with three changes:
PATCH-1 adds a helper function to get mc pointer
PATCH-2 adds support for clients that don't exist in DTB
PATCH-3 adds PCI support accordingly
Changelog
v1->v2
* Added PATCH-1 suggested by Dmitry
* Reworked PATCH-2 to unify certain code
Prvi
Previously the driver relies on bus_set_iommu() in .probe() to call
in .probe_device() function so each client can poll iommus property
in DTB to configure fwspec via tegra_smmu_configure(). According to
the comments in .probe(), this is a bit of a hack. And this doesn't
work for a client that does
This can be used by both tegra-smmu and tegra20-devfreq drivers.
Suggested-by: Dmitry Osipenko
Signed-off-by: Nicolin Chen
---
Changelog
v1->v2
* N/A
drivers/memory/tegra/mc.c | 23 +++
include/soc/tegra/mc.h| 1 +
2 files changed, 24 insertions(+)
diff --git a/driv
This patch simply adds support for PCI devices. Also reverses
bus_set_iommu in tegra_smmu_remove().
Signed-off-by: Nicolin Chen
---
Changelog
v1->v2
* Added error-out labels in tegra_smmu_probe()
* Dropped pci_request_acs() since IOMMU core would call it.
drivers/iommu/tegra-smmu.c | 33
On 9/25/20 1:43 AM, Jarkko Sakkinen wrote:
> On Thu, Sep 24, 2020 at 10:58:33AM -0400, Ross Philipson wrote:
>> From: "Daniel P. Smith"
>>
>> This commit introduces an abstraction for TPM1.2 and TPM2.0 devices
>> above the TPM hardware interface.
>>
>> Signed-off-by: Daniel P. Smith
>> Signed-off
Hi Thomas,
On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
This is the second version of providing a base to support device MSI (non
PCI based) and on top of that support for IMS (Interrupt Message Storm)
based devices in a halfways architecture independent way.
The first version can be found here
On 24 Sep 2020 11:54, Auger Eric wrote:
> Hi,
>
> Adding Al in the loop
>
> On 9/24/20 11:38 AM, Michael S. Tsirkin wrote:
> > On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wrote:
> >> On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael S. Tsirkin wrote:
> >>> OK so this looks good. Can yo
On Thu, Sep 24, 2020 at 11:00 AM Ross Philipson
wrote:
>
> The SHA algorithms are necessary to measure configuration information into
> the TPM as early as possible before using the values. This implementation
> uses the established approach of #including the SHA libraries directly in
> the code s
On Tue, 29 Sep 2020 09:18:22 +0200
Auger Eric wrote:
> Hi all,
>
> [also correcting some outdated email addresses + adding Lorenzo in cc]
>
> On 9/29/20 12:42 AM, Alex Williamson wrote:
> > On Mon, 28 Sep 2020 21:50:34 +0200
> > Eric Auger wrote:
> >
> >> VFIO currently exposes the usable I
29.09.2020 09:13, Nicolin Chen пишет:
> This is used to protect potential race condition at use_count.
> since probes of client drivers, calling attach_dev(), may run
> concurrently.
>
> Signed-off-by: Nicolin Chen
> ---
It's always better not to mix success and error code paths in order to
keep
29.09.2020 09:13, Nicolin Chen пишет:
> The tegra_smmu_group_get was added to group devices in different
> SWGROUPs and it'd return a NULL group pointer upon a mismatch at
> tegra_smmu_find_group(), so for most of clients/devices, it very
> likely would mismatch and need a fallback generic_device_g
On Tue, 29 Sep 2020 09:40:37 +0800, Yu Kuai wrote:
> if of_find_device_by_node() succeed, qcom_iommu_of_xlate() doesn't have
> a corresponding put_device(). Thus add put_device() to fix the exception
> handling for this function implementation.
Applied to will (for-joerg/arm-smmu/updates), thanks!
On Tue, Sep 29, 2020 at 10:03:47AM -0400, Ross Philipson wrote:
> On 9/25/20 3:18 PM, Arvind Sankar wrote:
> > You will also need to avoid initializing data with symbol addresses.
> >
> > .long mle_header
> > .long sl_stub_entry
> > .long sl_gdt
> >
...
> >
> > The other two are more
On 9/25/20 3:18 PM, Arvind Sankar wrote:
> On Fri, Sep 25, 2020 at 10:56:43AM -0400, Ross Philipson wrote:
>> On 9/24/20 1:38 PM, Arvind Sankar wrote:
>>> On Thu, Sep 24, 2020 at 10:58:35AM -0400, Ross Philipson wrote:
>>>
diff --git a/arch/x86/boot/compressed/head_64.S
b/arch/x86/boot/c
Hi Jacob,
On 9/25/20 6:32 PM, Jacob Pan wrote:
> IOMMU generic layer already does sanity checks on UAPI data for version
> match and argsz range based on generic information.
>
> This patch adjusts the following data checking responsibilities:
> - removes the redundant version check from VT-d dri
Hi Jacob,
On 9/25/20 6:32 PM, Jacob Pan wrote:
> IOMMU user APIs are responsible for processing user data. This patch
> changes the interface such that user pointers can be passed into IOMMU
> code directly. Separate kernel APIs without user pointers are introduced
> for in-kernel users of the UAP
On 2020/9/29 6:13, Will Deacon wrote:
> On Mon, 28 Sep 2020 16:32:02 +0800, Zhou Wang wrote:
>> In arm_smmu_evtq_thread, reading event queue is from consumer pointer,
>> which has no address dependency on producer pointer, prog_reg(MMIO) and
>> event queue memory(Normal memory) can disorder. So the
Hi Christoph,
On 9/29/20 8:03 AM, Christoph Hellwig wrote:
> On Mon, Sep 28, 2020 at 09:50:36PM +0200, Eric Auger wrote:
>> VFIO currently exposes the usable IOVA regions through the
>> VFIO_IOMMU_GET_INFO ioctl. However it fails to take into account
>> the dma_mask of the devices within the conta
Hi all,
[also correcting some outdated email addresses + adding Lorenzo in cc]
On 9/29/20 12:42 AM, Alex Williamson wrote:
> On Mon, 28 Sep 2020 21:50:34 +0200
> Eric Auger wrote:
>
>> VFIO currently exposes the usable IOVA regions through the
>> VFIO_IOMMU_GET_INFO ioctl / VFIO_IOMMU_TYPE1_INF
55 matches
Mail list logo
