Re: [Xen-devel] [PATCH 28/44] sparc: remove arch specific dma_supported implementations
Hi Christoph,
On Thu, Jun 8, 2017 at 11:25 PM, Christoph Hellwig <h...@lst.de> wrote:
> Usually dma_supported decisions are done by the dma_map_ops instance.
> Switch sparc to that model by providing a ->dma_supported instance for
> sbus that always returns false, and implementations tailored to the sun4u
> and sun4v cases for sparc64, and leave it unimplemented for PCI on
> sparc32, which means always supported.
>
> Signed-off-by: Christoph Hellwig <h...@lst.de>
> ---
> arch/sparc/include/asm/dma-mapping.h | 3 ---
> arch/sparc/kernel/iommu.c| 40
> +++-
> arch/sparc/kernel/ioport.c | 22 ++--
> arch/sparc/kernel/pci_sun4v.c| 17 +++
> 4 files changed, 39 insertions(+), 43 deletions(-)
>
> diff --git a/arch/sparc/kernel/ioport.c b/arch/sparc/kernel/ioport.c
> index dd081d557609..12894f259bea 100644
> --- a/arch/sparc/kernel/ioport.c
> +++ b/arch/sparc/kernel/ioport.c
> @@ -401,6 +401,11 @@ static void sbus_sync_sg_for_device(struct device *dev,
> struct scatterlist *sg,
> BUG();
> }
>
> +static int sbus_dma_supported(struct device *dev, u64 mask)
> +{
> + return 0;
> +}
> +
I'm guessing there's a few places that have DMA ops but DMA isn't
actually supported. Why not have a common method for this, maybe
"dma_not_supported"?
> static const struct dma_map_ops sbus_dma_ops = {
> .alloc = sbus_alloc_coherent,
> .free = sbus_free_coherent,
> @@ -410,6 +415,7 @@ static const struct dma_map_ops sbus_dma_ops = {
> .unmap_sg = sbus_unmap_sg,
> .sync_sg_for_cpu= sbus_sync_sg_for_cpu,
> .sync_sg_for_device = sbus_sync_sg_for_device,
> + .dma_supported = sbus_dma_supported,
> };
>
> static int __init sparc_register_ioport(void)
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 0/3] checkpatch: handling of memory barriers
Hi Michael, On Mon, Jan 11, 2016 at 10:04 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Jan 11, 2016 at 12:59:25PM +0200, Michael S. Tsirkin wrote: >> As part of memory barrier cleanup, this patchset >> extends checkpatch to make it easier to stop >> incorrect memory barrier usage. >> >> This replaces the checkpatch patches in my series >> arch: barrier cleanup + barriers for virt >> and will be included in the pull request including >> the series. >> >> changes from v3: >> rename smp_barrier_stems to barrier_stems >> as suggested by Julian Calaby. > > In fact it was Joe Perches that suggested it. > Sorry about the confusion. I was about to point that out. FWIW this entire series is: Acked-by: Julian Calaby <julian.cal...@gmail.com> Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] checkpatch: add virt barriers
Hi Michael,
On Mon, Jan 11, 2016 at 9:35 PM, Michael S. Tsirkin <m...@redhat.com> wrote:
> On Sun, Jan 10, 2016 at 02:52:16PM -0800, Joe Perches wrote:
>> On Mon, 2016-01-11 at 09:13 +1100, Julian Calaby wrote:
>> > On Mon, Jan 11, 2016 at 6:31 AM, Michael S. Tsirkin <m...@redhat.com>
>> > wrote:
>> > > Add virt_ barriers to list of barriers to check for
>> > > presence of a comment.
>> []
>> > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
>> []
>> > > @@ -5133,7 +5133,8 @@ sub process {
>> > > }x;
>> > > my $all_barriers = qr{
>> > > $barriers|
>> > > - smp_(?:$smp_barrier_stems)
>> > > + smp_(?:$smp_barrier_stems)|
>> > > + virt_(?:$smp_barrier_stems)
>> >
>> > Sorry I'm late to the party here, but would it make sense to write this as:
>> >
>> > (?:smp|virt)_(?:$smp_barrier_stems)
>>
>> Yes. Perhaps the name might be better as barrier_stems.
>>
>> Also, ideally this would be longest match first or use \b
>> after the matches so that $all_barriers could work
>> successfully without a following \s*\(
>>
>> my $all_barriers = qr{
>> (?:smp|virt)_(?:barrier_stems)|
>> $barriers)
>> }x;
>>
>> or maybe add separate $smp_barriers and $virt_barriers
>>
>> it doesn't matter much in any case
>
> OK just to clarify - are you OK with merging the patch as is?
> Refactorings can come as patches on top if required.
I don't really care either way, I was just asking if it was possible.
If you don't see any value in that change, then don't make it.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] checkpatch: add virt barriers
Hi Michael,
On Mon, Jan 11, 2016 at 6:31 AM, Michael S. Tsirkin <m...@redhat.com> wrote:
> Add virt_ barriers to list of barriers to check for
> presence of a comment.
>
> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
> ---
> scripts/checkpatch.pl | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 15cfca4..4466579 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -5133,7 +5133,8 @@ sub process {
> }x;
> my $all_barriers = qr{
> $barriers|
> - smp_(?:$smp_barrier_stems)
> + smp_(?:$smp_barrier_stems)|
> + virt_(?:$smp_barrier_stems)
Sorry I'm late to the party here, but would it make sense to write this as:
(?:smp|virt)_(?:$smp_barrier_stems)
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] [SCSI] libsas: Kconfig: Enable SATA compatibility by default
Hi Ian, On Sat, May 2, 2015 at 12:36 AM, Ian Jackson ian.jack...@eu.citrix.com wrote: SATA controllers support SATA disks. The kernel should be able to Do you mean SAS controllers? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
