All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olav Haugan <ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	will.deacon-5wv7dgnIgG8@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v4 1/1] iommu-api: Add map_sg/unmap_sg functions
Date: Thu, 07 Aug 2014 14:52:56 -0700	[thread overview]
Message-ID: <53E3F538.8030000@codeaurora.org> (raw)
In-Reply-To: <20140807062410.GC17340@ulmo>

On 8/6/2014 11:24 PM, Thierry Reding wrote:
> On Wed, Aug 06, 2014 at 04:28:45PM -0700, Olav Haugan wrote:
>> On 8/6/2014 1:17 PM, Joerg Roedel wrote:
>>> On Wed, Aug 06, 2014 at 10:08:55AM -0700, Olav Haugan wrote:
>>>> so you are suggesting that I check in "bus_set_iommu()" whether the
>>>> driver has set the map_sg/unmap_sg function pointers or not and if not
>>>> set it to the default? Is bus_set_iommu() the only way drivers can set
>>>> up the callbacks?
>>>
>>> This doesn't work as the iommu_ops are now const. You have to either
>>> update the iommu drivers individually to point to the default function,
>>> or you do the check in the API function itself and fall back to the
>>> default it no call-back is provided.
>>>
>>
>> Ok, then I think it is better to just leave the fallback where it is now
>> in the function itself.
> 
> What Konrad was suggesting is what I also proposed. The idea is to
> implement a fallback as standalone function, then make all drivers use
> that by default in the struct iommu_ops that they register. When drivers
> implement an optimized version they can simply replace the fallback
> implementation with their own.
> 

Ok, I can do that. I misunderstood the point of the fallback. I thought
the point of the fallback was to catch drivers that forget/neglect to
implement this callback. If that is not a concern I will update my patch
to create a separate function that I will point all existing drivers to.

Thanks,

Olav

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

WARNING: multiple messages have this Message-ID (diff)
From: ohaugan@codeaurora.org (Olav Haugan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/1] iommu-api: Add map_sg/unmap_sg functions
Date: Thu, 07 Aug 2014 14:52:56 -0700	[thread overview]
Message-ID: <53E3F538.8030000@codeaurora.org> (raw)
In-Reply-To: <20140807062410.GC17340@ulmo>

On 8/6/2014 11:24 PM, Thierry Reding wrote:
> On Wed, Aug 06, 2014 at 04:28:45PM -0700, Olav Haugan wrote:
>> On 8/6/2014 1:17 PM, Joerg Roedel wrote:
>>> On Wed, Aug 06, 2014 at 10:08:55AM -0700, Olav Haugan wrote:
>>>> so you are suggesting that I check in "bus_set_iommu()" whether the
>>>> driver has set the map_sg/unmap_sg function pointers or not and if not
>>>> set it to the default? Is bus_set_iommu() the only way drivers can set
>>>> up the callbacks?
>>>
>>> This doesn't work as the iommu_ops are now const. You have to either
>>> update the iommu drivers individually to point to the default function,
>>> or you do the check in the API function itself and fall back to the
>>> default it no call-back is provided.
>>>
>>
>> Ok, then I think it is better to just leave the fallback where it is now
>> in the function itself.
> 
> What Konrad was suggesting is what I also proposed. The idea is to
> implement a fallback as standalone function, then make all drivers use
> that by default in the struct iommu_ops that they register. When drivers
> implement an optimized version they can simply replace the fallback
> implementation with their own.
> 

Ok, I can do that. I misunderstood the point of the fallback. I thought
the point of the fallback was to catch drivers that forget/neglect to
implement this callback. If that is not a concern I will update my patch
to create a separate function that I will point all existing drivers to.

Thanks,

Olav

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2014-08-07 21:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-01  0:54 [PATCH v4 0/1] Add iommu map_sg/unmap_sg API Olav Haugan
2014-08-01  0:54 ` Olav Haugan
2014-08-01  0:54 ` [PATCH v4 1/1] iommu-api: Add map_sg/unmap_sg functions Olav Haugan
2014-08-01  0:54   ` Olav Haugan
     [not found]   ` <1406854484-3848-2-git-send-email-ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-08-01  8:22     ` Will Deacon
2014-08-01  8:22       ` Will Deacon
     [not found]       ` <20140801082228.GC15733-5wv7dgnIgG8@public.gmane.org>
2014-08-01 16:44         ` Olav Haugan
2014-08-01 16:44           ` Olav Haugan
     [not found]           ` <53DBC3F1.40705-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-08-04 18:03             ` Olav Haugan
2014-08-04 18:03               ` Olav Haugan
2014-08-05 15:13     ` Konrad Rzeszutek Wilk
2014-08-05 15:13       ` Konrad Rzeszutek Wilk
     [not found]       ` <20140805151323.GB19709-0iZWjJA6G8GSPmnEAIUT9EEOCMrvLtNR@public.gmane.org>
2014-08-06 17:08         ` Olav Haugan
2014-08-06 17:08           ` Olav Haugan
     [not found]           ` <53E26127.1040805-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-08-06 20:17             ` Joerg Roedel
2014-08-06 20:17               ` Joerg Roedel
     [not found]               ` <20140806201740.GW9809-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-08-06 23:28                 ` Olav Haugan
2014-08-06 23:28                   ` Olav Haugan
2014-08-07  6:24                   ` Thierry Reding
2014-08-07  6:24                     ` Thierry Reding
2014-08-07 21:52                     ` Olav Haugan [this message]
2014-08-07 21:52                       ` Olav Haugan
2014-08-08 17:14                       ` Konrad Rzeszutek Wilk
2014-08-08 17:14                         ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53E3F538.8030000@codeaurora.org \
    --to=ohaugan-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.