Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions

protection value handling drivers/iommu/omap-iommu.c | 68 -- 1 file changed, 23 insertions(+), 45 deletions(-) Until I have time to read and think about the rest, for the series, Reviewed-by: Sakari Ailus sakari.ai...@iki.fi -- Sakari Ailus sakari.ai

Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions

/iommu/2013-November/index.html -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

[RFC 1/4] iommu: iova: Move iova cache management to the iova library

alloc_iova_mem() or free_iova_mem(), and correspondingly iova_cache_put() after using the IOVA library. Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com --- drivers/iommu/intel-iommu.c | 34 +++- drivers/iommu/iova.c| 48

[RFC 0/4] Separate the IOVA library from the intel-iommu driver

Hi, This set separates the IOVA library from the intel-iommu driver, and makes it usable for other implementations (such as DMA mapping) as well. While I don't have a DMA mapping implementation to share at the moment, the patches might be useful for the others in the meantime and I wouldn't mind

[RFC 4/4] mm: EXPORT_SYMBOL_GPL({find_vm_area,get_vm_area_caller});

These APIs are needed in DMA mapping API implementation as a module. Device specific IOMMUs with associated DMA mapping implementations should be buildable as modules. Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com --- mm/vmalloc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[RFC 2/4] iommu: iova: Export symbols

(); This is necessary in order to use the iova library from a kernel module. Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com --- drivers/iommu/iova.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c index 6bc7022..e9e62f4 100644

Re: [RFC PATCH 0/4] Genericise the IOVA allocator

anyway. [1]:http://thread.gmane.org/gmane.linux.ports.arm.kernel/331299 [2]:http://article.gmane.org/gmane.linux.kernel.iommu/7436 -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.com ___ iommu mailing list iommu@lists.linux-foundation.org https

Re: [PATCH v2 25/26] omap3isp: Move to videobuf2

be used to allocate virtually contiguous memory, then what could be? This looks like a bug in __iommu_map_sg() to me. Cc the iommu list. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk ___ iommu mailing list iommu

[PATCH 1/1] PCI: Add function 1 DMA alias quirk for Marvell 9120

Marvell 9120 SATA controller has the same issue as a number of others, use the same quirk for this one. The other quirks were added by patch PCI: Add function 1 DMA alias quirk for Marvell devices (commit id cc346a4714a59d08c118e8f33fd86692d3563133). Signed-off-by: Sakari Ailus sakari.ai

Re: [PATCH 1/1] PCI: Add function 1 DMA alias quirk for Marvell 9120

Ping. (Cc Alex.) Sakari Ailus wrote: Marvell 9120 SATA controller has the same issue as a number of others, use the same quirk for this one. The other quirks were added by patch PCI: Add function 1 DMA alias quirk for Marvell devices (commit id cc346a4714a59d08c118e8f33fd86692d3563133

Re: [PATCH 1/1] PCI: Add function 1 DMA alias quirk for Marvell 9120

Hi Alex, Alex Williamson wrote: On Thu, 2015-05-21 at 12:54 +0300, Sakari Ailus wrote: Ping. (Cc Alex.) You can add my ack, but the linux-pci list is the proper list to get this upstream. I suggest resending it there. Thanks, Thank you for your reply and ack; I'll resend

[PATCH 0/4] Separate the IOVA library from the intel-iommu driver

Hi folks, This set separates the IOVA library from the intel-iommu driver, and makes it usable for other implementations (such as DMA mapping) as well. The RFC set can be found here:

[PATCH 2/4] iommu: iova: Export symbols

(); put_iova_domain(); reserve_iova(); copy_reserved_iova(); Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com --- drivers/iommu/iova.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c index 400f4d1..dd87123 100644 --- a/drivers/iommu

[PATCH 1/4] iommu: iova: Move iova cache management to the iova library

This is necessary to separate intel-iommu from the iova library. Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com --- drivers/iommu/intel-iommu.c | 6 ++-- drivers/iommu/iova.c| 83 ++--- include/linux/iova.h| 4 +-- 3 files

Re: [PATCH v3 03/12] intel-ipu3: Add DMA API implementation

plementations have their own DMA ops currently. I agree it'd be nice to unify these in the long run but I don't think this stands apart from the rest currently --- except that the MMU is only used by a single PCI device, the same which it is contained in. -- Kind rega

Re: [PATCH v3 02/12] intel-ipu3: mmu: implement driver

ging the L1 page table > > +* at runtime, so we use shadow L1 tables with CPU L2 table pointers > > +* per-domain and update the L1 table on domain attach and detach. > > +*/ > > + mmu->l1pt = ipu3_mmu_alloc_page_table(0); > > + if (!mmu->l1pt) { > > + ret = -ENOMEM; > > + goto fail_mmu; > > + } > > + > > + mmu->group = iommu_group_alloc(); > > + if (!mmu->group) { > > + ret = -ENOMEM; > > + goto fail_l1pt; > > + } > > + > > + pteval = IPU3_ADDR2PTE(virt_to_phys(mmu->l1pt)); > > + writel(pteval, mmu->base + REG_L1_PHYS); > > + ipu3_mmu_tlb_invalidate(mmu); > > + > > + bus_set_iommu(bus, >ops); > > + > > + return mmu; > > Rather than playing tricks with bus->ops, it's probably better for the > bus code to stash imgu->mmu directly in the other subdevices' archdata > as it creates them; that seems the cleanest way. Right now there aren't any: there's a PCI device + the MMU struct device created by the PCI device driver, while the MMU itself is part of that PCI device. I guess you could alternatively create another on the bus and designate that for the "real" driver to control the PCI device. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 03/12] intel-ipu3: Add DMA API implementation

> + iommu_dma_cleanup(); > +} > +EXPORT_SYMBOL_GPL(ipu3_dmamap_cleanup); > + > +MODULE_AUTHOR("Tomasz Figa <tf...@chromium.org>"); > +MODULE_LICENSE("GPL v2"); > +MODULE_DESCRIPTION("IPU3 DMA mapping support"); > diff --git a/drivers/media/pci/intel/ipu3/ipu3-dmamap.h > b/drivers/media/pci/intel/ipu3/ipu3-dmamap.h > new file mode 100644 > index 000..fe5d0a4 > --- /dev/null > +++ b/drivers/media/pci/intel/ipu3/ipu3-dmamap.h > @@ -0,0 +1,22 @@ > +/* > + * Copyright (c) 2017 Intel Corporation. > + * Copyright (C) 2017 Google, Inc. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License version > + * 2 as published by the Free Software Foundation. > + * > + * 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. > + * > + */ > + > +#ifndef __IPU3_DMAMAP_H > +#define __IPU3_DMAMAP_H > + > +int ipu3_dmamap_init(struct device *dev, u64 dma_base, u64 size); > +void ipu3_dmamap_cleanup(struct device *dev); > + > +#endif -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

b/arch/arm/mm/dma-mapping.c > > index ab4f745..a40f03e 100644 > > --- a/arch/arm/mm/dma-mapping.c > > +++ b/arch/arm/mm/dma-mapping.c > > @@ -2358,6 +2358,7 @@ static void arm_teardown_iommu_dma_ops(struct device > *dev) > > __arm_iom

Re: [PATCH 02/12] intel-ipu3: mmu: implement driver

FT; > > Is virt_to_phys() correct here? I'm not an expert on x86 systems, but > since this is a PCI device, there might be some other memory mapping > involved. In theory yes --- if the IPU3 were behind an IOMMU managed by the Linux kernel. That kind of configuration wouldn't make much sense and any attempt to use such a configuration would probably fall apart with the assumption of single dma_ops, too. I have to say I'm not certain if anything else than kernel configuration would prevent this though. -- Regards, Sakari Ailus sakari.ai...@linux.intel.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 03/12] intel-ipu3: Add DMA API implementation

3 code, it looks like the whole PCI device is > non-coherent for some reason (e.g. you can see implicit cache flushes > for page tables). So I would have expected that a non-coherent variant > of x86 dma_ops is used for the PCI struct device, which would do cache > maintenance in its dm

Re: [PATCH 02/12] intel-ipu3: mmu: implement driver

move(struct device *dev) > >> +{ > >> + struct ipu3_mmu *mmu = dev_get_drvdata(dev); > >> + > >> + put_iova_domain(>iova_domain); > >> + iova_cache_put(); > > Don't we need to set the L1 table address to something invalid and > invalidate the TLB, so that the IOMMU doesn't reference the page freed > below anymore? I think the expectation is that if a device gets removed, its memory is unmapped by that time. Unmapping that memory will cause explicit TLB flush. -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 02/12] intel-ipu3: mmu: implement driver

Hi Tomasz, On Fri, Jun 09, 2017 at 02:59:10PM +0900, Tomasz Figa wrote: > On Fri, Jun 9, 2017 at 1:43 AM, Sakari Ailus <sakari.ai...@iki.fi> wrote: > >> >> +static void ipu3_mmu_domain_free(struct iommu_domain *dom) > >> >> +{ > >

Re: [PATCH v4 00/12] Intel IPU3 ImgU patchset

meaningful > use of them. For these reasons it has been chosen video buffers to pass Do you have a to-do list for this patchset? I think it would be useful to maintain one, in case not all the comments have been addressed. -- Sakari Ailus e-mail: sakari.ai...@iki.fi __

Re: [PATCH v4 03/12] intel-ipu3: Add IOMMU based dmamap support

gu->domain = NULL; > +} > +EXPORT_SYMBOL_GPL(ipu3_dmamap_exit); > + > +MODULE_AUTHOR("Tomasz Figa <tf...@chromium.org>"); > +MODULE_AUTHOR("Yong Zhi <yong@intel.com>"); > +MODULE_LICENSE("GPL v2"); > +MODULE_DESCRIPTION("IPU3 DMA mapping support"); > diff --git a/drivers/media/pci/intel/ipu3/ipu3-dmamap.h > b/drivers/media/pci/intel/ipu3/ipu3-dmamap.h > new file mode 100644 > index ..9b442a40ee06 > --- /dev/null > +++ b/drivers/media/pci/intel/ipu3/ipu3-dmamap.h > @@ -0,0 +1,33 @@ > +/* > + * Copyright (c) 2017 Intel Corporation. > + * Copyright (C) 2017 Google, Inc. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License version > + * 2 as published by the Free Software Foundation. > + * > + * 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. > + * > + */ > + > +#ifndef __IPU3_DMAMAP_H > +#define __IPU3_DMAMAP_H > + > +struct imgu_device; > + > +void *ipu3_dmamap_alloc(struct imgu_device *imgu, struct ipu3_css_map *map, > + size_t len); > +void ipu3_dmamap_free(struct imgu_device *imgu, struct ipu3_css_map *map); > + > +int ipu3_dmamap_map_sg(struct imgu_device *imgu, struct scatterlist *sglist, > +int nents, enum dma_data_direction dir, > +struct ipu3_css_map *map); > +void ipu3_dmamap_unmap(struct imgu_device *imgu, struct ipu3_css_map *map); > + > +int ipu3_dmamap_init(struct imgu_device *imgu); > +void ipu3_dmamap_exit(struct imgu_device *imgu); > + > +#endif > -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 02/12] intel-ipu3: Add mmu driver

goto fail_l2pt; > + > + /* Allocate the L1 page table. */ > + mmu->l1pt = ipu3_mmu_alloc_page_table(mmu->dummy_l2pt_pteval); > + if (!mmu->l1pt) { > + ret = -ENOMEM; > + goto fail_l2pts; > + } > + > + pteval =

Re: [PATCH v4 12/12] intel-ipu3: imgu top level pci device

2U > +#define IPU3_OUTPUT_MAX_WIDTH4480U > +#define IPU3_OUTPUT_MAX_HEIGHT 34004U > + > +struct ipu3_mem2mem2_buffer { > + /* Public fields */ > + struct vb2_v4l2_buffer vbb; /* Must be the first field */ > + > + /* Private fields */ > + struct list_head list; > +}; > + > +struct imgu_buffer { > + struct ipu3_mem2mem2_buffer m2m2_buf; /* Must be the first field */ > + struct ipu3_css_buffer css_buf; > + struct ipu3_css_map map; > +}; > + > +struct imgu_node_mapping { > + int css_queue; > + const char *name; > +}; > + > +/** > + * struct imgu_video_device > + * each node registers as video device and maintains its > + * own vb2_queue. > + */ > +struct imgu_video_device { > + const char *name; > + bool output;/* Frames to the driver? */ > + bool immutable; /* Can not be enabled/disabled */ > + bool enabled; > + int queued; /* Buffers already queued */ > + struct v4l2_format vdev_fmt;/* Currently set format */ > + > + /* Private fields */ > + struct video_device vdev; > + struct media_pad vdev_pad; > + struct v4l2_mbus_framefmt pad_fmt; > + struct vb2_queue vbq; > + struct list_head buffers; > + /* Protect vb2_queue and vdev structs*/ > + struct mutex lock; > + atomic_t sequence; > +}; > + > +/** > + * struct ipu3_mem2mem2_device - mem2mem device > + * this is the top level helper struct used by parent PCI device > + * to bind everything together for media operations. > + */ > +struct ipu3_mem2mem2_device { There's always 1:1 mapping between ipu3_mem2mem2_device and imgu_device. Could you merge the two? > + /* Public fields, fill before registering */ > + const char *name; > + const char *model; > + struct device *dev; > + int num_nodes; > + struct imgu_video_device *nodes; > + struct device *vb2_alloc_dev; > + const struct ipu3_mem2mem2_ops *ops; > + const struct vb2_mem_ops *vb2_mem_ops; > + unsigned int buf_struct_size; > + bool streaming; /* Public read only */ > + struct v4l2_ctrl_handler *ctrl_handler; > + > + /* Private fields */ > + struct v4l2_device v4l2_dev; > + struct media_device media_dev; > + struct media_pipeline pipeline; > + struct v4l2_subdev subdev; > + struct media_pad *subdev_pads; > + struct v4l2_file_operations v4l2_file_ops; > +}; > + > +/** > + * struct ipu3_mem2mem2_ops - mem2mem2 ops > + * defines driver specific callback APIs like > + * start stream. > + */ > +struct ipu3_mem2mem2_ops { > + int (*s_stream)(struct ipu3_mem2mem2_device *m2m2_dev, int enable); > +}; > + > +/* > + * imgu_device -- ImgU (Imaging Unit) driver > + */ > +struct imgu_device { > + struct pci_dev *pci_dev; > + void __iomem *base; > + > + /* Internally enabled queues */ > + struct { > + struct ipu3_css_map dmap; > + struct ipu3_css_buffer dummybufs[IMGU_MAX_QUEUE_DEPTH]; > + } queues[IPU3_CSS_QUEUES]; > + struct imgu_video_device mem2mem2_nodes[IMGU_NODE_NUM]; > + bool queue_enabled[IMGU_NODE_NUM]; > + > + /* Delegate v4l2 support */ > + struct ipu3_mem2mem2_device mem2mem2; > + /* MMU driver for css */ > + struct device *mmu; > + struct iommu_domain *domain; > + struct iova_domain iova_domain; > + /* css - Camera Sub-System */ > + struct ipu3_css css; > + > + /* > + * Coarse-grained lock to protect > + * m2m2_buf.list and css->queue > + */ > + struct mutex lock; > + /* Forbit streaming and buffer queuing during system suspend. */ > + struct mutex qbuf_lock; > + struct { > + struct v4l2_rect eff; /* effective resolution */ > + struct v4l2_rect bds; /* bayer-domain scaled resolution*/ > + struct v4l2_rect gdc; /* gdc output resolution */ > + } rect; > + /* Indicate if system suspend take place while imgu is streaming. */ > + bool suspend_in_stream; > + /* Used to wait for FW buffer queue drain. */ > + wait_queue_head_t buf_drain_wq; > +}; > + > +int imgu_node_to_queue(int node); > +int imgu_map_node(struct imgu_device *imgu, int css_queue); > +int imgu_queue_buffers(struct imgu_device *imgu, bool initial); > + > +int ipu3_v4l2_register(struct imgu_device *dev); > +int ipu3_v4l2_unregister(struct imgu_device *dev); > +void ipu3_v4l2_buffer_done(struct vb2_buffer *vb, enum vb2_buffer_state > state); > + > +#endif > -- > 2.7.4 > -- Sakari Ailus e-mail: sakari.ai...@iki.fi ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/1] iova: Allow compiling the library without IOMMU support

Hi Laurent, On Thu, Jan 03, 2019 at 12:52:00AM +0200, Laurent Pinchart wrote: > Hi Sakari, > > Thank you for the patch. > > On Wednesday, 2 January 2019 23:16:57 EET Sakari Ailus wrote: > > Drivers such as the Intel IPU3 ImgU driver use the IOVA library to manage > &g

Re: [PATCH v8 05/14] media: rkisp1: add Rockchip ISP1 subdev driver

On Thu, Aug 15, 2019 at 07:29:59PM +0900, Tomasz Figa wrote: > On Thu, Aug 15, 2019 at 5:25 PM Sakari Ailus > wrote: > > > > Hi Helen, > > > > On Wed, Aug 14, 2019 at 09:58:05PM -0300, Helen Koike wrote: > > > > ... > > > > > &g

Re: [PATCH v4 01/14] dt-bindings: Add binding for MT2712 MIPI-CSI2

are > > multiple device and the register definition does not duplicate. > > I guess we didn't catch that in the review yet. It should be fixed. > > > You > > recommend adding MT2712 support on top of the MT8183 series, do you mean > > that "mediatek,mt2712-mipicsi" shou

Re: [V3, 2/2] media: i2c: Add Omnivision OV02A10 camera sensor driver

On Thu, Sep 05, 2019 at 07:53:37PM +0900, Tomasz Figa wrote: > On Thu, Sep 5, 2019 at 7:45 PM Sakari Ailus > wrote: > > > > Hi Dongchun, > > > > On Thu, Sep 05, 2019 at 05:41:05PM +0800, Dongchun Zhu wrote: > > > > ... > > > > &g

Re: [V2, 2/2] media: i2c: Add more sensor modes for ov8856 camera sensor

lso not have access to similar configurations (output size, cropping etc.) that now exist in the driver. I'll review the patch itself soonish. -- Regards, Sakari Ailus sakari.ai...@linux.intel.com

Re: [PATCH] media: staging: ipu3: Enable IOVA API only when IOMMU support is enabled

UPPORT but that's not declared in its Kconfig entry. I wonder if adding that would be the right way to fix this. Cc'ing the IOMMU list. > select VIDEOBUF2_DMA_SG > help > This is the Video4Linux2 driver for Intel IPU3 image processing unit, -- Regards, Sakari Ailus sakari.ai...@linux.intel.com

Re: [PATCH 04/29] staging: media: ipu3: use vmap instead of reimplementing it

On Tue, Apr 14, 2020 at 03:13:23PM +0200, Christoph Hellwig wrote: > Just use vmap instead of messing with vmalloc internals. > > Signed-off-by: Christoph Hellwig > Acked-by: Peter Zijlstra (Intel) Thanks! Acked-by: Sakari Ailus --

Re: [PATCH 17/18] media/omap3isp: Clean up IOMMU workaround

-8<--- -- Kind regards, Sakari Ailus ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 17/18] media/omap3isp: Clean up IOMMU workaround

On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote: > On 2020-08-20 17:53, Sakari Ailus wrote: > > Hi Robin, > > > > On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote: > > > Now that arch/arm is wired up for default domains and iommu-dma, device

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_igfx); > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_igfx); > @@ -5657,6 +5683,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1632, > quirk_iommu_igfx)

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

; > I noticed there was a typo in the recipient list: > stable.vger.kernel.org -> sta...@vger.kernel.org > > no code change for resent. When you're submitting a patch and want it reach the stable kernels, you'll need to add a Cc tag: Cc: sta...@vger.kernel.org But not actual

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

On Tue, Apr 20, 2021 at 02:55:33PM +0300, Andy Shevchenko wrote: > On Tue, Apr 20, 2021 at 01:56:40PM +0300, Sakari Ailus wrote: > > On Tue, Apr 20, 2021 at 06:34:26PM +0800, Bingbu Cao wrote: > > > On 4/20/21 6:20 PM, Andy Shevchenko wrote: > > > > On Tue, Apr 20, 20

Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

On Tue, Apr 20, 2021 at 05:54:57PM +0300, Andy Shevchenko wrote: > On Tue, Apr 20, 2021 at 05:37:27PM +0300, Sakari Ailus wrote: > > On Tue, Apr 20, 2021 at 02:55:33PM +0300, Andy Shevchenko wrote: > > > On Tue, Apr 20, 2021 at 01:56:40PM +0300, Sakari Ailus wrote: > >