On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch is adding 6 bitmaps, three to PE and three to PHB, to track
The patch is also removing 2 arrays (io_segmap and m32_segmap), what is
that all about? Also, there was no m64_segmap, now there is, needs an
explanation may be.
the consumed by
On 08/06/2015 02:11 PM, Gavin Shan wrote:
There're 3 windows (IO, M32 and M64) for PHB, root port and upstream
These are actually IO, non-prefetchable and prefetchable windows which
happen to be IO, 32bit and 64bit windows but this has nothing to do with
the M32/M64 BAR registers in P7IOC/PHB
Hi Stewart,
On 08/10/2015 05:53 AM, Stewart Smith wrote:
> Shilpasri G Bhat writes:
>> Add OPAL_MSG_OCC message definition to opal_message_type to receive
>> OCC events like reset, load and throttled. Host performance can be
>> affected when OCC is reset or OCC throttles the max Pstate.
>> We can
On 08/06/2015 02:11 PM, Gavin Shan wrote:
For P7IOC, the whole available DMA32 space, which is below the
MEM32 space, is divided evenly into 256MB segments. The number
of continuous segments assigned to one particular PE depends on
the PE's DMA weight that is calculated based on the type of each
Hello,
MPC8349 has general IRQ numbered 0-7,
It is required to bind these IRQs with some routine , i.e. they are
not used with any specific driver.
- Should they be configured as gpios in device tree so that we can use
the gpio as irq in linux ? Is there any example ?
- After configuration, can t
On 08/10/2015 07:11 AM, Stewart Smith wrote:
> Shilpasri G Bhat writes:
>> diff --git a/drivers/cpufreq/powernv-cpufreq.c
>> b/drivers/cpufreq/powernv-cpufreq.c
>> index d0c18c9..a634199 100644
>> --- a/drivers/cpufreq/powernv-cpufreq.c
>> +++ b/drivers/cpufreq/powernv-cpufreq.c
>> @@ -33,6 +33
On 10-08-15, 13:21, Shilpasri G Bhat wrote:
> Okay will change the messages.
This series is already applied by Rafael. So send a new patch if there
is any code change. Else, just let it go :)
--
viresh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.o
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch cleans up DMA32 in pci-ioda.c. It shouldn't introduce
behavioural changes:
* Rename various fields in "struct pnv_phb" and "struct pnv_ioda_pe"
as 32-bits DMA should be related to "DMA", not "TCE".
s/dma_weight/dma32_weight/ is ok (
Hi Michael,
> Back in the olden days we added support for using 64K pages to map the
> SPU (Synergistic Processing Unit) local store on Cell, when the main
> kernel was using 4K pages.
>
> This was useful at the time because distros were using 4K pages, but
> using 64K pages on the SPUs could red
Shilpasri G Bhat writes:
>> Also, do we export this information via sysfs somewhere? It would seem
>> to want to go along with other cpufreq/cpu info there.
>
> No we don't export the throttling status of the cpu via sysfs. Since the
> throttling state is common across the chip, the per_cpu export
On 08/06/2015 02:11 PM, Gavin Shan wrote:
For P7IOC, the whole available DMA32 space, which is below the
MEM32 space, is divided evenly into 256MB segments. The number
of continuous segments assigned to one particular PE depends on
the PE's DMA weight that is calculated based on the type of each
On Tue, 2015-05-05 at 08:05:43 UTC, Mahesh Salgaonkar wrote:
> From: Mahesh Salgaonkar
>
> In the event of unrecovered HMI the existing code panics as soon as
> it receives the first unrecovered HMI event. This makes host to report
> partial information about HMIs before panic. There may be more
On Fri, 2015-24-04 at 08:54:44 UTC, "Naveen N. Rao" wrote:
> Add a new powerpc-specific trace clock using the timebase register,
> similar to x86-tsc. This gives us
> - a fast, monotonic, hardware clock source for trace entries, and
> - a clock that can be used to correlate events across cpus as we
On Thu, 2015-16-04 at 12:18:50 UTC, weiyj...@163.com wrote:
> From: Wei Yongjun
>
> In case of error, the functions platform_get_resource() and kmalloc()
> returns NULL not ERR_PTR(). The IS_ERR() test in the return value check
> should be replaced with NULL test.
>
> Signed-off-by: Wei Yongjun
On Wed, 2015-29-07 at 04:07:22 UTC, Daniel Axtens wrote:
> Previously, when attaching a context in dedicated mode, we ignored
> the result of add_process_element, which could potentially fail.
>
> If add_process_element returns and error, pass it back to the caller.
>
> Signed-off-by: Daniel Axte
On Tue, 2015-04-08 at 11:18:56 UTC, Mahesh Salgaonkar wrote:
> From: Mahesh Salgaonkar
>
> Invoke new opal_cec_reboot2() call with reboot type
> OPAL_REBOOT_PLATFORM_ERROR (for unrecoverable HMI interrupts) to inform
> BMC/OCC about this error, so that BMC can collect relevant data for error
> an
On Fri, 2015-31-07 at 12:14:20 UTC, Paul Bolle wrote:
> wf_find_control(), wf_find_sensor(), and wf_is_overtemp() are exported
> but unused. Remove these three functions.
>
> Signed-off-by: Paul Bolle
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a368c29cf105485d2c34
cheers
On Mon, 2015-29-06 at 21:30:39 UTC, Joe Perches wrote:
> break; break; isn't useful.
>
> Remove one.
>
> Signed-off-by: Joe Perches
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a825ac078b50266fb091
cheers
___
Linuxppc-dev mailin
On Fri, 2015-12-06 at 02:26:37 UTC, Kevin Hao wrote:
> Use %pR to simplify the debug code. This also make the debug info more
> readable.
>
> Signed-off-by: Kevin Hao
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ae2a84b4074cff81957b
cheers
_
On Tue, 2015-05-05 at 08:04:58 UTC, Mahesh Salgaonkar wrote:
> From: Mahesh Salgaonkar
>
> The V2 version of HMI event now carries additional information for
> Malfunction Alert. It now contains error information about CORE and NX
> checkstop. This patch checks and displays the check stop reason
On Fri, 2015-31-07 at 12:12:20 UTC, Paul Bolle wrote:
> wf_critical_overtemp() is exported. But nothing uses that export.
> That's unsurprising because there's no header that defines it. Stop
> exporting that function and make it static.
>
> Signed-off-by: Paul Bolle
Applied to powerpc next, tha
On Fri, 2015-31-07 at 15:54:38 UTC, Mahesh Salgaonkar wrote:
> From: Mahesh Salgaonkar
>
> On non-recoverable MCE errors in kernel space, Linux kernel panics
> and system reboots. On BMC based system opal-prd runs as a daemon
> in the host. Hence, kernel crash may prevent opal-prd to detect and
>
On Fri, 2015-31-07 at 12:08:58 UTC, Paul Bolle wrote:
> wf_unregister_client() increments the client count when a client
> unregisters. That is obviously incorrect. Decrement that client count
> instead.
>
> Fixes: 75722d3992f5 ("[PATCH] ppc64: Thermal control for SMU based machines")
>
> Signed-
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The original implementation of pnv_ioda_setup_dma() iterates the
list of PEs and configures the DMA32 space for them one by one.
The function was designed to be called during PHB fixup time.
When configuring PE's DMA32 space in pcibios_setup_bridge(), in
On 08/06/2015 02:11 PM, Gavin Shan wrote:
On P7IOC, the whole DMA32 space is divided evenly to 256MB segments.
Each PE can consume one or multiple DMA32 segments. Current code
doesn't trace the available DMA32 segments and those consumed by
one particular PE. It's conflicting with PCI hotplug.
T
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Each PHB maintains an array helping to translate RID (Request
ID) to PE# with the assumption that PE# takes 8 bits, indicating
that we can't have more than 256 PEs. However, pci_dn->pe_number
already had 4-bytes for the PE#.
The patch extends the PE# cap
From: Viresh Kumar
Migrate powerpc driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.
This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.
We weren't doing anyt
From: Hou Zhiqiang
The c293pcie board is an endpoint device and it doesn't need PM,
so remove hooks pcibios_fixup_phb and pcibios_fixup_bus.
Signed-off-by: Hou Zhiqiang
---
Test on c293pcie board:
V2:
Rename the title of this patch.
Remove pcibios_fixup_bus that isn't used in EP.
arch
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Several functions used to configure PE take pe_number to indentify
PE instance. As the pe_number is included in PE instance after it
is reserved or allocated. It's convienent for those functions to
return PE instance which includes the required pe_number.
> -Original Message-
> From: Wood Scott-B07421
> Sent: 2015年8月1日 1:24
> To: Hou Zhiqiang-B48286
> Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Hu Mingkai-
> B21284; Wang Dongsheng-B40534
> Subject: Re: [PATCH] c293/pci: remove hook pcibios_fixup_phb
>
> On Fri, 2015-07-3
On Mon, Aug 10, 2015 at 10:48 AM, Ran Shalit wrote:
> Hello,
>
> MPC8349 has general IRQ numbered 0-7,
> It is required to bind these IRQs with some routine , i.e. they are
> not used with any specific driver.
>
> - Should they be configured as gpios in device tree so that we can use
> the gpio as
On 08/06/2015 02:11 PM, Gavin Shan wrote:
This renames the fields related to PE# in "struct pnv_phb" for
better reflecting of their usages as Alexey suggested. It doesn't
introduce behavioural changes.
Signed-off-by: Gavin Shan
Makes sense to move this to the beginning of the patchset as pat
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The available PE#, represented by a bitmap in the PHB, is allocated
in ascending order.
Available PE# is available exactly because it is not allocated ;)
It conflicts with the fact that M64 segments are
assigned in same order. In order to avoid the co
This fixes the wrapper functions kvm_umap_hva_hv and the function
kvm_unmap_hav_range_hv to return the return value of the function
kvm_handle_hva or kvm_handle_hva_range that they are wrapped to
call internally rather then always making the caller of these
wrapper functions think they always run s
On Mon, 2015-08-10 at 10:23 +0800, Huang, Yuanjie wrote:
> Hi Scott,
>
> On 08/08/2015 10:29 AM, Scott Wood wrote:
> > [Please wrap commit messages at around 74 columns]
> Ok, I will when sending a new version.
> >
> > On Fri, Aug 07, 2015 at 02:58:10PM +0800, Yuanjie Huang wrote:
> > > PowerPC B
Hello David,
Thank you for your feedback.
I understand your concerns regarding the FMan driver, we've come a long way
from where we started but still there are issues.
The community support is critical for getting the code to the desired quality
level and I appreciate the support I receive from
On Fri, 2015-08-07 at 07:49 +0530, Madhavan Srinivasan wrote:
>
> On Thursday 06 August 2015 06:35 PM, Anshuman Khandual wrote:
> > This patch just replaces hard coded values with existing
>
> Please drop "This patch just" and start with "Replace hard ..."
>
> https://www.kernel.org/doc/Docu
On 8/5/2015 9:11 PM, Gavin Shan wrote:
> This introduces one more argument to of_fdt_unflatten_tree()
> to specify the root node for the FDT blob, which is going to be
> unflattened. In the result, the function can be used to unflatten
> FDT blob, which represents device sub-tree in PowerNV hotplug
On 8/5/2015 9:11 PM, Gavin Shan wrote:
> This changes of_fdt_unflatten_tree() so that it returns the allocated
> memory chunk for unflattened device-tree, which can be released once
> it's obsoleted.
>
> Signed-off-by: Gavin Shan
> ---
> drivers/of/fdt.c | 11 ++-
> include/linux/o
On Sun, 2015-08-09 at 22:18 +0300, Ran Shalit wrote:
> On Sun, Aug 9, 2015 at 9:27 AM, Ran Shalit wrote:
> >
> > Hi ,
> >
> > I reboot the board, with the new device tree localbus, but I don't
> > have any new /dev/mtdX entry for the NOR flash.
> > There is no HW issue, becuase we can R/W access
On Mon, Aug 10, 2015 at 04:30:09PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>The patch enables M64 window on P7IOC, which has been enabled on
>>PHB3. Different from PHB3 where 16 M64 BARs are supported and each
>>of them can be owned by one particular PE# exclu
On Mon, Aug 10, 2015 at 04:05:40PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>The series of patches intend to support PCI slot for PowerPC PowerNV platform,
>>which is running on top of skiboot firmware. The patchset requires
>>corresponding
>>changes from skib
On Mon, Aug 10, 2015 at 05:16:40PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>The patch is adding 6 bitmaps, three to PE and three to PHB, to track
>
>The patch is also removing 2 arrays (io_segmap and m32_segmap), what is that
>all about? Also, there was no m64
On Mon, Aug 10, 2015 at 05:40:08PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>There're 3 windows (IO, M32 and M64) for PHB, root port and upstream
>
>These are actually IO, non-prefetchable and prefetchable windows which happen
>to be IO, 32bit and 64bit windows
On Mon, Aug 10, 2015 at 06:07:27PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>The patch cleans up DMA32 in pci-ioda.c. It shouldn't introduce
>>behavioural changes:
>>
>>* Rename various fields in "struct pnv_phb" and "struct pnv_ioda_pe"
>> as 32-bits
On Mon, Aug 10, 2015 at 07:31:11PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>The original implementation of pnv_ioda_setup_dma() iterates the
>>list of PEs and configures the DMA32 space for them one by one.
>>The function was designed to be called during PHB f
On Mon, Aug 10, 2015 at 07:43:48PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>On P7IOC, the whole DMA32 space is divided evenly to 256MB segments.
>>Each PE can consume one or multiple DMA32 segments. Current code
>>doesn't trace the available DMA32 segments and
On Mon, Aug 10, 2015 at 07:53:02PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>Each PHB maintains an array helping to translate RID (Request
>>ID) to PE# with the assumption that PE# takes 8 bits, indicating
>>that we can't have more than 256 PEs. However, pci_dn
On Mon, Aug 10, 2015 at 08:02:20PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>Several functions used to configure PE take pe_number to indentify
>>PE instance. As the pe_number is included in PE instance after it
>>is reserved or allocated. It's convienent for t
On Tue, Aug 11, 2015 at 12:21:16AM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>This renames the fields related to PE# in "struct pnv_phb" for
>>better reflecting of their usages as Alexey suggested. It doesn't
>>introduce behavioural changes.
>>
>>Signed-off-by:
On Tue, Aug 11, 2015 at 12:39:02AM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2015 02:11 PM, Gavin Shan wrote:
>>The available PE#, represented by a bitmap in the PHB, is allocated
>>in ascending order.
>
>Available PE# is available exactly because it is not allocated ;)
>
Yeah, will correct it.
On Mon, Aug 10, 2015 at 03:42:32PM -0700, Frank Rowand wrote:
>On 8/5/2015 9:11 PM, Gavin Shan wrote:
Frank, thanks for your comments. All of them will be included
in next revision.
Thanks,
Gavin
>> This changes of_fdt_unflatten_tree() so that it returns the allocated
>> memory chunk for unflatt
On Mon, Aug 10, 2015 at 03:42:13PM -0700, Frank Rowand wrote:
>On 8/5/2015 9:11 PM, Gavin Shan wrote:
>> This introduces one more argument to of_fdt_unflatten_tree()
>> to specify the root node for the FDT blob, which is going to be
>> unflattened. In the result, the function can be used to unflatt
On 08/11/2015 09:45 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 04:30:09PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch enables M64 window on P7IOC, which has been enabled on
PHB3. Different from PHB3 where 16 M64 BARs are supported and each
of them c
On 08/11/2015 10:03 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 05:16:40PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch is adding 6 bitmaps, three to PE and three to PHB, to track
The patch is also removing 2 arrays (io_segmap and m32_segmap), what
On Mon, 2015-08-10 at 13:40 +0300, Ran Shalit wrote:
> On Mon, Aug 10, 2015 at 10:48 AM, Ran Shalit wrote:
> > Hello,
> >
> > MPC8349 has general IRQ numbered 0-7,
> > It is required to bind these IRQs with some routine , i.e. they are
> > not used with any specific driver.
> >
> > - Should they
On 08/11/2015 10:12 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 05:40:08PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
There're 3 windows (IO, M32 and M64) for PHB, root port and upstream
These are actually IO, non-prefetchable and prefetchable windows which
On 08/11/2015 10:29 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 07:31:11PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The original implementation of pnv_ioda_setup_dma() iterates the
list of PEs and configures the DMA32 space for them one by one.
The function
On 08/11/2015 10:38 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 07:53:02PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Each PHB maintains an array helping to translate RID (Request
ID) to PE# with the assumption that PE# takes 8 bits, indicating
that we can't
On 08/11/2015 10:43 AM, Gavin Shan wrote:
On Tue, Aug 11, 2015 at 12:39:02AM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The available PE#, represented by a bitmap in the PHB, is allocated
in ascending order.
Available PE# is available exactly because it is no
On Tue, 28 Jul 2015 15:28:34 +1000
Daniel Axtens wrote:
> If the PCI channel has gone down, don't attempt to poke the hardware.
>
> We need to guard every time cxl_whatever_(read|write) is called. This
> is because a call to those functions will dereference an offset into an
> mmio register, and
On Tue, 28 Jul 2015 15:28:35 +1000
Daniel Axtens wrote:
> Previously the SPA was allocated and freed upon entering and leaving
> AFU-directed mode. This causes some issues for error recovery - contexts
> hold a pointer inside the SPA, and they may persist after the AFU has
> been detached.
>
> W
On Tue, 28 Jul 2015 15:28:36 +1000
Daniel Axtens wrote:
> Check if an IRQ is mapped before releasing it.
>
> This will simplify future EEH code by allowing unconditional unmapping
> of IRQs.
>
Acked-by: Cyril Bur
> Signed-off-by: Daniel Axtens
> ---
> drivers/misc/cxl/irq.c | 9 +
>
On Tue, Aug 11, 2015 at 5:29 AM, Scott Wood wrote:
> On Mon, 2015-08-10 at 13:40 +0300, Ran Shalit wrote:
>> On Mon, Aug 10, 2015 at 10:48 AM, Ran Shalit wrote:
>> > Hello,
>> >
>> > MPC8349 has general IRQ numbered 0-7,
>> > It is required to bind these IRQs with some routine , i.e. they are
>>
On Tue, 2015-08-11 at 06:45 +0300, Ran Shalit wrote:
> On Tue, Aug 11, 2015 at 5:29 AM, Scott Wood wrote:
> > On Mon, 2015-08-10 at 13:40 +0300, Ran Shalit wrote:
> > > On Mon, Aug 10, 2015 at 10:48 AM, Ran Shalit
> > > wrote:
> > > > Hello,
> > > >
> > > > MPC8349 has general IRQ numbered 0-7,
On Tue, 28 Jul 2015 15:28:37 +1000
Daniel Axtens wrote:
> - MMIO pointer unmapping is guarded by a null pointer check.
>However, iounmap doesn't null the pointer, just invalidate it.
>Therefore, explicitly null the pointer after unmapping.
>
> - afu_desc_mmio also needs to be unmapped.
On Tue, 28 Jul 2015 15:28:43 +1000
Daniel Axtens wrote:
> CONFIG_CXL_EEH is for CXL's EEH related code.
>
> As well as the EEH callbacks, it should guard sysfs and
> kernel API changes that are only required for CXL EEH.
>
> We now have all the pieces in place, so add it now.
>
Reviewed-by: C
On Tue, 28 Jul 2015 15:28:39 +1000
Daniel Axtens wrote:
> As with an adapter, some aspects of initialisation are done only once
> in the lifetime of an AFU: for example, allocating memory, or setting
> up sysfs/debugfs files.
>
> However, we may want to be able to do some parts of the initialisa
> Hey Daniel, keeping in mind I can't exactly test it, and that I don't know the
> ins and outs of CAPI, the code looks nice and it makes sence to me.
>
Thanks!
> Some very minor points,
>
> Otherwise
>
> Acked-by: Cyril Bur
>
> >
> > +static inline bool cxl_adapter_link_ok(struct cxl *cxl
On Tue, 2015-08-11 at 13:42 +1000, Cyril Bur wrote:
> On Tue, 28 Jul 2015 15:28:35 +1000
> Daniel Axtens wrote:
>
> > Previously the SPA was allocated and freed upon entering and leaving
> > AFU-directed mode. This causes some issues for error recovery - contexts
> > hold a pointer inside the SPA
On Tue, 28 Jul 2015 15:28:40 +1000
Daniel Axtens wrote:
> If the driver doesn't participate in EEH, the AFUs will be removed
> by cxl_remove, which will be invoked by EEH.
>
> If the driver does particpate in EEH, the vPHB needs to stick around
> so that the it can particpate.
>
> In both cases
On Tue, 28 Jul 2015 15:28:38 +1000
Daniel Axtens wrote:
> Some aspects of initialisation are done only once in the lifetime of
> an adapter: for example, allocating memory for the adapter,
> allocating the adapter number, or setting up sysfs/debugfs files.
>
> However, we may want to be able to
On Tue, Aug 11, 2015 at 6:47 AM, Scott Wood wrote:
> On Tue, 2015-08-11 at 06:45 +0300, Ran Shalit wrote:
>> On Tue, Aug 11, 2015 at 5:29 AM, Scott Wood wrote:
>> > On Mon, 2015-08-10 at 13:40 +0300, Ran Shalit wrote:
>> > > On Mon, Aug 10, 2015 at 10:48 AM, Ran Shalit
>> > > wrote:
>> > > > Hel
Hi Cyril,
> > - PCI regions are allocated in cxl_map_adapter_regs.
> >Therefore they should be released in unmap, not elsewhere.
> >
>
> You've changed the order in which cxl_remove_adapter() does its work, which,
> I'm sure you've considered and it's fine, best to check.
Yeah, I have consi
74 matches
Mail list logo
