* [PATCH v4 7/8] dt-bindings: iio: document envelope-detector bindings
From: Peter Rosin @ 2016-11-08 11:58 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Rob Herring, Mark Rutland, Daniel Baluta,
Slawomir Stepien, Thomas Gleixner, linux-iio, devicetree
In-Reply-To: <1478606339-31253-1-git-send-email-peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../bindings/iio/adc/envelope-detector.txt | 54 ++++++++++++++++++++++
MAINTAINERS | 6 +++
2 files changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/envelope-detector.txt b/Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
new file mode 100644
index 000000000000..27544bdd4478
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
@@ -0,0 +1,54 @@
+Bindings for ADC envelope detector using a DAC and a comparator
+
+The DAC is used to find the peak level of an alternating voltage input
+signal by a binary search using the output of a comparator wired to
+an interrupt pin. Like so:
+ _
+ | \
+ input +------>-------|+ \
+ | \
+ .-------. | }---.
+ | | | / |
+ | dac|-->--|- / |
+ | | |_/ |
+ | | |
+ | | |
+ | irq|------<-------'
+ | |
+ '-------'
+
+Required properties:
+- compatible: Should be "axentia,tse850-envelope-detector"
+- io-channels: Channel node of the dac to be used for comparator input.
+- io-channel-names: Should be "dac".
+- interrupt specification for one client interrupt,
+ see ../../interrupt-controller/interrupts.txt for details.
+- interrupt-names: Should be "comp".
+
+Example:
+
+ &i2c {
+ dpot: mcp4651-104@28 {
+ compatible = "microchip,mcp4651-104";
+ reg = <0x28>;
+ #io-channel-cells = <1>;
+ };
+ };
+
+ dac: dac {
+ compatible = "dpot-dac";
+ vref-supply = <®_3v3>;
+ io-channels = <&dpot 0>;
+ io-channel-names = "dpot";
+ #io-channel-cells = <1>;
+ };
+
+ envelope-detector {
+ compatible = "axentia,tse850-envelope-detector";
+ io-channels = <&dac 0>;
+ io-channel-names = "dac";
+
+ interrupt-parent = <&gpio>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "comp";
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 583c6c93b6f3..0e13066ca3a2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6132,6 +6132,12 @@ F: Documentation/ABI/testing/sysfs-bus-iio-dac-dpot-dac
F: Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
F: drivers/iio/dac/dpot-dac.c
+IIO ENVELOPE DETECTOR
+M: Peter Rosin <peda@axentia.se>
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
+
IIO SUBSYSTEM AND DRIVERS
M: Jonathan Cameron <jic23@kernel.org>
R: Hartmut Knaack <knaack.h@gmx.de>
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 3/3] ARM: dts: da850: add usb device node
From: kbuild test robot @ 2016-11-08 20:34 UTC (permalink / raw)
To: Axel Haslam
Cc: kbuild-all, gregkh, stern, nsekhar, khilman, david, robh+dt,
linux-usb, linux-kernel, linux-arm-kernel, devicetree,
Axel Haslam
In-Reply-To: <20161108185831.17683-4-ahaslam@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
Hi Axel,
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on next-20161108]
[cannot apply to robh/for-next v4.9-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Axel-Haslam/USB-ohci-da8xx-Add-devicetree-bindings/20161109-031338
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/da850-lcdk.dts:89.1-9 Label or path usb_phy not found
FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 21781 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] ARM: dts: da850: add usb device node
From: kbuild test robot @ 2016-11-08 20:34 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz, nsekhar-l0cyMroinI0,
khilman-DgEjT+Ai2ygdnm+yROfE0A, david-nq/r/kbU++upp/zk7JDF2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Axel Haslam
In-Reply-To: <20161108185831.17683-4-ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
Hi Axel,
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on next-20161108]
[cannot apply to robh/for-next v4.9-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Axel-Haslam/USB-ohci-da8xx-Add-devicetree-bindings/20161109-031338
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/da850-lcdk.dts:89.1-9 Label or path usb_phy not found
FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 21781 bytes --]
^ permalink raw reply
* [PATCH 3/3] ARM: dts: da850: add usb device node
From: kbuild test robot @ 2016-11-08 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108185831.17683-4-ahaslam@baylibre.com>
Hi Axel,
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on next-20161108]
[cannot apply to robh/for-next v4.9-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Axel-Haslam/USB-ohci-da8xx-Add-devicetree-bindings/20161109-031338
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/da850-lcdk.dts:89.1-9 Label or path usb_phy not found
FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 21781 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161109/5e5ea637/attachment-0001.gz>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V3 05/10] intel_iommu: support device iotlb descriptor
From: Michael S. Tsirkin @ 2016-11-08 20:31 UTC (permalink / raw)
To: Jason Wang
Cc: Peter Xu, Eduardo Habkost, qemu-devel, vkaplans, wexu,
cornelia.huck, pbonzini, Richard Henderson
In-Reply-To: <ccf5553b-b766-41b5-a06f-987bff65a1bd@redhat.com>
On Tue, Nov 08, 2016 at 02:54:19PM +0800, Jason Wang wrote:
>
>
> On 2016年11月08日 07:35, Peter Xu wrote:
> > On Mon, Nov 07, 2016 at 03:09:50PM +0800, Jason Wang wrote:
> >
> > [...]
> >
> > > +static bool vtd_process_device_iotlb_desc(IntelIOMMUState *s,
> > > + VTDInvDesc *inv_desc)
> > > +{
> > > + VTDAddressSpace *vtd_dev_as;
> > > + IOMMUTLBEntry entry;
> > Since "entry" is allocated on the stack...
> >
> > [...]
> >
> > > + entry.target_as = &vtd_dev_as->as;
> > > + entry.addr_mask = sz - 1;
> > > + entry.iova = addr;
> > > + memory_region_notify_iommu(entry.target_as->root, entry);
> > ... here we need to assign entry.perm explicitly to IOMMU_NONE, right?
> >
> > Also I think it'll be nice that we set all the fields even not used,
> > to avoid rubbish from the stack passed down to notifier handlers.
> >
> > [...]
>
> This is better, if no other comments on the series I will post a patch on
> top to fix this.
If you do, pls remember to use the fixup! prefix.
> >
> > > +static bool x86_iommu_device_iotlb_prop_get(Object *o, Error **errp)
> > > +{
> > > + X86IOMMUState *s = X86_IOMMU_DEVICE(o);
> > > + return s->dt_supported;
> > > +}
> > > +
> > > +static void x86_iommu_device_iotlb_prop_set(Object *o, bool value, Error **errp)
> > > +{
> > > + X86IOMMUState *s = X86_IOMMU_DEVICE(o);
> > > + s->dt_supported = value;
> > > +}
> > > +
> > > static void x86_iommu_instance_init(Object *o)
> > > {
> > > X86IOMMUState *s = X86_IOMMU_DEVICE(o);
> > > @@ -114,6 +126,11 @@ static void x86_iommu_instance_init(Object *o)
> > > s->intr_supported = false;
> > > object_property_add_bool(o, "intremap", x86_iommu_intremap_prop_get,
> > > x86_iommu_intremap_prop_set, NULL);
> > > + s->dt_supported = false;
> > > + object_property_add_bool(o, "device-iotlb",
> > > + x86_iommu_device_iotlb_prop_get,
> > > + x86_iommu_device_iotlb_prop_set,
> > > + NULL);
> > Again, a nit-pick here is to use Property for "device-iotlb":
> >
> > static Property vtd_properties[] = {
> > DEFINE_PROP_UINT32("device-iotlb", X86IOMMUState, dt_supported, false),
> > DEFINE_PROP_END_OF_LIST(),
> > };
> >
> > However not worth a repost.
> >
> > Thanks,
> >
> > -- peterx
> >
>
> We may want to share this with AMD IOMMU. (Looking at AMD IOMMU codes, its
> device-iotlb support is buggy).
>
> Thanks
^ permalink raw reply
* Re: auto stop of scrubbing and deep scrubbing while backfilling or recovering
From: Sage Weil @ 2016-11-08 20:30 UTC (permalink / raw)
To: Wido den Hollander; +Cc: Stefan Priebe - Profihost AG, ceph-devel
In-Reply-To: <1661441329.1631.1478628592614@ox.pcextreme.nl>
On Tue, 8 Nov 2016, Wido den Hollander wrote:
> > Op 8 november 2016 om 15:19 schreef Sage Weil <sage@newdream.net>:
> >
> >
> > On Tue, 8 Nov 2016, Wido den Hollander wrote:
> > > > Op 8 november 2016 om 9:35 schreef Stefan Priebe - Profihost AG <s.priebe@profihost.ag>:
> > > >
> > > >
> > > > Hello,
> > > >
> > > > i'm wondering if anybody has already thought about automatically
> > > > stopping srub and deep-scrub in case of backfilling or recovering. I've
> > > > seen several situations where scrubbing massivly raises the latency
> > > > while doing backfilling or recovering.
> > > >
> > >
> > > Seems like a sane change to me, but maybe a dev has a better option. I
> > > don't think a stop is easy, but a 'noscrub' flag could be set inside the
> > > OSD.
> > >
> > > Maybe a config option: osd_scrub_during_recovery
> > >
> > > Defaults to true, but can be set to false by the admin.
> > >
> > > Before a scrub starts the OSD will check if there is recovery /
> > > backfilling active on the OSD and if so it will not initiate the scrub.
> >
> > Yeah, it seems reasonable. I think there are two basic options:
> >
> > - Disable scrubbing locally on each OSD if it has scrubbing PGs. Two
> > unrelated OSDs would be free to scrub and backfill at the same time.
> >
> > - Disable scrubbing globally if any pgs are backfilling. The reasoning
> > here is that if backfilling is increasing the latency on some PGs, we
> > don't want to increase the latency on others (by scrubbing) too.
> >
> > The other consideration is that if backfil is happening it probably
> > doesn't mean we want to prevent scrubbing indefinitely. Instead, I'd
> > suggest increasing the scrub intervals by some factor (e.g., 2x).
> >
> > The first option would probably be a change in the scrub scheduling in
> > the OSD.
> >
>
> I would go for the first one. Imagine a large cluster where one backfill is busy, that would otherwise halt all scrubs while only a few OSDs are involved.
>
> Option one isn't that hard to implement either I think.
I added a card to trello: https://trello.com/b/ugTc2QFH/ceph-backlog
Thanks!
sage
^ permalink raw reply
* Re: [PATCH 2/2] iio: gyro: mpu3050: add I2C dependency
From: Jonathan Cameron @ 2016-11-08 20:29 UTC (permalink / raw)
To: Linus Walleij, Arnd Bergmann
Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdY2aMcv_Sko7PQGn3DE1nm=osypGcR5bWUx69CzUj-o1Q@mail.gmail.com>
On 08/11/16 15:40, Linus Walleij wrote:
> On Tue, Nov 8, 2016 at 2:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> The new mpu3050 driver fails to build if I2C is disabled:
>>
>> drivers/iio/built-in.o: In function `mpu3050_i2c_driver_exit':
>> mpu3050-i2c.c:(.exit.text+0x17f): undefined reference to `i2c_del_driver'
>> drivers/iio/built-in.o: In function `mpu3050_i2c_driver_init':
>> mpu3050-i2c.c:(.init.text+0x215): undefined reference to `i2c_register_driver'
>>
>> This adds a Kconfig dependency to ensure we only build it when I2C
>> is available.
>>
>> Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Applied. Thanks.
Jonathan
>
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v2] ARC: [plat-eznps] remove IPI clear from SMP operations
From: Noam Camus @ 2016-11-08 9:58 UTC (permalink / raw)
To: vgupta; +Cc: linux-snps-arc, linux-kernel, Noam Camus
From: Noam Camus <noamca@mellanox.com>
Today we register to plat_smp_ops.clear() method which actually
is acking the IPI.
However this is already taking care by our irqchip driver specifically
by the irq_chip.irq_eoi() method.
This is perfect timing where it should be done and no special handling
is needed at plat_smp_ops.clear().
Signed-off-by: Noam Camus <noamca@mellanox.com>
---
arch/arc/plat-eznps/smp.c | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arc/plat-eznps/smp.c b/arch/arc/plat-eznps/smp.c
index 5e901f8..56a4c85 100644
--- a/arch/arc/plat-eznps/smp.c
+++ b/arch/arc/plat-eznps/smp.c
@@ -140,16 +140,10 @@ static void eznps_init_per_cpu(int cpu)
mtm_enable_core(cpu);
}
-static void eznps_ipi_clear(int irq)
-{
- write_aux_reg(CTOP_AUX_IACK, 1 << irq);
-}
-
struct plat_smp_ops plat_smp_ops = {
.info = smp_cpuinfo_buf,
.init_early_smp = eznps_init_cpumasks,
.cpu_kick = eznps_smp_wakeup_cpu,
.ipi_send = eznps_ipi_send,
.init_per_cpu = eznps_init_per_cpu,
- .ipi_clear = eznps_ipi_clear,
};
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] drm/nouveau: Drop superfluous DRM_SWITCH_POWER_DYNAMIC_OFF checks
From: Peter Wu @ 2016-11-08 20:29 UTC (permalink / raw)
To: Lukas Wunner; +Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Ben Skeggs
In-Reply-To: <0136d21975f52582f9cfe3ea313c3173c657c286.1478605864.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
On Tue, Nov 08, 2016 at 12:57:00PM +0100, Lukas Wunner wrote:
> nouveau's ->suspend and ->resume callbacks are currently skipped if the
> device's status is either DRM_SWITCH_POWER_OFF (powered off by
> vga_switcheroo manual power control) or DRM_SWITCH_POWER_DYNAMIC_OFF
> (runtime suspended).
>
> In the former case this makes sense since the device is powered off
> behind the PM core's back: It will try to execute the ->suspend and
> ->resume callbacks upon system sleep, not knowing that the device is
> inaccessible. Therefore the callbacks have to become no-ops.
>
> However the latter case doesn't make any sense because the PM core
> never calls the ->suspend and ->resume callbacks of runtime suspended
> devices: Such devices are either runtime resumed before going to system
> sleep (see call to pm_runtime_resume() in drivers/pci/pci-driver:
> pci_pm_suspend()) or they are left runtime suspended over the entire
> system suspend/resume process (search for "direct_complete" in
> drivers/base/power/main.c).
>
> Consequently the DRM_SWITCH_POWER_DYNAMIC_OFF checks are superfluous.
> Drop them.
>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
It is better to rely on the official documentation rather than the
implementation. Luckily, Documentation/power/pci.txt supports the claim:
2.4.1. System Suspend
When the system is going into a sleep state in which the contents of memory will
be preserved, such as one of the ACPI sleep states S1-S3, the phases are:
prepare, suspend, suspend_noirq.
[..]
The pci_pm_prepare() routine first puts the device into the "fully functional"
state with the help of pm_runtime_resume(). [..]
So indeed we can be sure that the device is runtime-resumed before
suspend. System resume is not documented explicitly, but it seems
reasonable that the device is not runtime-suspended between system
suspend and resume.
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
> ---
> drivers/gpu/drm/nouveau/nouveau_drm.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 9876e6f..d91d092 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -666,8 +666,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> int ret;
>
> - if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF ||
> - drm_dev->switch_power_state == DRM_SWITCH_POWER_DYNAMIC_OFF)
> + if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
> return 0;
>
> ret = nouveau_do_suspend(drm_dev, false);
> @@ -688,8 +687,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> int ret;
>
> - if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF ||
> - drm_dev->switch_power_state == DRM_SWITCH_POWER_DYNAMIC_OFF)
> + if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
> return 0;
>
> pci_set_power_state(pdev, PCI_D0);
> --
> 2.10.1
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* Re: Summary of LPC guest MSI discussion in Santa Fe (was: Re: [RFC 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 (Alt II))
From: Christoffer Dall @ 2016-11-08 20:29 UTC (permalink / raw)
To: Will Deacon
Cc: Alex Williamson, Eric Auger, eric.auger.pro, marc.zyngier,
robin.murphy, joro, tglx, jason, linux-arm-kernel, kvm, drjones,
linux-kernel, pranav.sawargaonkar, iommu, punit.agrawal,
diana.craciun, ddutile, benh, arnd, jcm, dwmw
In-Reply-To: <20161108024559.GA20591@arm.com>
Hi Will,
On Tue, Nov 08, 2016 at 02:45:59AM +0000, Will Deacon wrote:
> Hi all,
>
> I figured this was a reasonable post to piggy-back on for the LPC minutes
> relating to guest MSIs on arm64.
>
> On Thu, Nov 03, 2016 at 10:02:05PM -0600, Alex Williamson wrote:
> > We can always have QEMU reject hot-adding the device if the reserved
> > region overlaps existing guest RAM, but I don't even really see how we
> > advise users to give them a reasonable chance of avoiding that
> > possibility. Apparently there are also ARM platforms where MSI pages
> > cannot be remapped to support the previous programmable user/VM
> > address, is it even worthwhile to support those platforms? Does that
> > decision influence whether user programmable MSI reserved regions are
> > really a second class citizen to fixed reserved regions? I expect
> > we'll be talking about this tomorrow morning, but I certainly haven't
> > come up with any viable solutions to this. Thanks,
>
> At LPC last week, we discussed guest MSIs on arm64 as part of the PCI
> microconference. I presented some slides to illustrate some of the issues
> we're trying to solve:
>
> http://www.willdeacon.ukfsn.org/bitbucket/lpc-16/msi-in-guest-arm64.pdf
>
> Punit took some notes (thanks!) on the etherpad here:
>
> https://etherpad.openstack.org/p/LPC2016_PCI
>
> although the discussion was pretty lively and jumped about, so I've had
> to go from memory where the notes didn't capture everything that was
> said.
>
> To summarise, arm64 platforms differ in their handling of MSIs when compared
> to x86:
>
> 1. The physical memory map is not standardised (Jon pointed out that
> this is something that was realised late on)
> 2. MSIs are usually treated the same as DMA writes, in that they must be
> mapped by the SMMU page tables so that they target a physical MSI
> doorbell
> 3. On some platforms, MSIs bypass the SMMU entirely (e.g. due to an MSI
> doorbell built into the PCI RC)
> 4. Platforms typically have some set of addresses that abort before
> reaching the SMMU (e.g. because the PCI identifies them as P2P).
>
> All of this means that userspace (QEMU) needs to identify the memory
> regions corresponding to points (3) and (4) and ensure that they are
> not allocated in the guest physical (IPA) space. For platforms that can
> remap the MSI doorbell as in (2), then some space also needs to be
> allocated for that.
>
> Rather than treat these as separate problems, a better interface is to
> tell userspace about a set of reserved regions, and have this include
> the MSI doorbell, irrespective of whether or not it can be remapped.
Is my understanding correct, that you need to tell userspace about the
location of the doorbell (in the IOVA space) in case (2), because even
though the configuration of the device is handled by the (host) kernel
through trapping of the BARs, we have to avoid the VFIO user programming
the device to create other DMA transactions to this particular address,
since that will obviously conflict and either not produce the desired
DMA transactions or result in unintended weird interrupts?
Thanks,
Christoffer
^ permalink raw reply
* Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
From: Jacek Anaszewski @ 2016-11-08 20:29 UTC (permalink / raw)
To: David Lechner, Jacek Anaszewski, Richard Purdie
Cc: linux-kernel, linux-leds, Marcel Holtmann, Pavel Machek
In-Reply-To: <0970c634-61ac-8ad7-088a-e47419c23455@lechnology.com>
On 11/08/2016 08:08 PM, David Lechner wrote:
>
>
> On 11/8/16 5:26 AM, Jacek Anaszewski wrote:
>> Hi David,
>>
>
>>> +struct uleds_device {
>>> + struct uleds_user_dev user_dev;
>>> + struct led_classdev led_cdev;
>>> + struct mutex mutex;
>>> + enum uleds_state state;
>>> + wait_queue_head_t waitq;
>>> + unsigned char brightness;
>>
>> I've just noticed that this is wrong, since LED subsystem
>> brightness type is enum led_brightness, i.e. int.
>> LED_FULL (255) value is a legacy enum value that can be overridden
>> by max_brightness property.
>>
>> Please submit a fix so that I could merge it with the original
>> patch before sending it upstream.
>>
>> Thanks,
>> Jacek Anaszewski
>>
>
> The brightness should be a 32-bit integer then?
Exactly.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe (was: Re: [RFC 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 (Alt II))
From: Christoffer Dall @ 2016-11-08 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108024559.GA20591@arm.com>
Hi Will,
On Tue, Nov 08, 2016 at 02:45:59AM +0000, Will Deacon wrote:
> Hi all,
>
> I figured this was a reasonable post to piggy-back on for the LPC minutes
> relating to guest MSIs on arm64.
>
> On Thu, Nov 03, 2016 at 10:02:05PM -0600, Alex Williamson wrote:
> > We can always have QEMU reject hot-adding the device if the reserved
> > region overlaps existing guest RAM, but I don't even really see how we
> > advise users to give them a reasonable chance of avoiding that
> > possibility. Apparently there are also ARM platforms where MSI pages
> > cannot be remapped to support the previous programmable user/VM
> > address, is it even worthwhile to support those platforms? Does that
> > decision influence whether user programmable MSI reserved regions are
> > really a second class citizen to fixed reserved regions? I expect
> > we'll be talking about this tomorrow morning, but I certainly haven't
> > come up with any viable solutions to this. Thanks,
>
> At LPC last week, we discussed guest MSIs on arm64 as part of the PCI
> microconference. I presented some slides to illustrate some of the issues
> we're trying to solve:
>
> http://www.willdeacon.ukfsn.org/bitbucket/lpc-16/msi-in-guest-arm64.pdf
>
> Punit took some notes (thanks!) on the etherpad here:
>
> https://etherpad.openstack.org/p/LPC2016_PCI
>
> although the discussion was pretty lively and jumped about, so I've had
> to go from memory where the notes didn't capture everything that was
> said.
>
> To summarise, arm64 platforms differ in their handling of MSIs when compared
> to x86:
>
> 1. The physical memory map is not standardised (Jon pointed out that
> this is something that was realised late on)
> 2. MSIs are usually treated the same as DMA writes, in that they must be
> mapped by the SMMU page tables so that they target a physical MSI
> doorbell
> 3. On some platforms, MSIs bypass the SMMU entirely (e.g. due to an MSI
> doorbell built into the PCI RC)
> 4. Platforms typically have some set of addresses that abort before
> reaching the SMMU (e.g. because the PCI identifies them as P2P).
>
> All of this means that userspace (QEMU) needs to identify the memory
> regions corresponding to points (3) and (4) and ensure that they are
> not allocated in the guest physical (IPA) space. For platforms that can
> remap the MSI doorbell as in (2), then some space also needs to be
> allocated for that.
>
> Rather than treat these as separate problems, a better interface is to
> tell userspace about a set of reserved regions, and have this include
> the MSI doorbell, irrespective of whether or not it can be remapped.
Is my understanding correct, that you need to tell userspace about the
location of the doorbell (in the IOVA space) in case (2), because even
though the configuration of the device is handled by the (host) kernel
through trapping of the BARs, we have to avoid the VFIO user programming
the device to create other DMA transactions to this particular address,
since that will obviously conflict and either not produce the desired
DMA transactions or result in unintended weird interrupts?
Thanks,
Christoffer
^ permalink raw reply
* Re: Summary of LPC guest MSI discussion in Santa Fe (was: Re: [RFC 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 (Alt II))
From: Christoffer Dall @ 2016-11-08 20:29 UTC (permalink / raw)
To: Will Deacon
Cc: arnd-r2nGTMty4D4, drjones-H+wXaHxf7aLQT0dZR+AlfA,
jason-NLaQJdtUoK4Be96aLqz0jA, kvm-u79uwXL29TY76Z2rM5mHXA,
marc.zyngier-5wv7dgnIgG8, benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r,
punit.agrawal-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w,
dwmw-vV1OtcyAfmbQXOPxS62xeg, jcm-H+wXaHxf7aLQT0dZR+AlfA,
tglx-hfZtesqFncYOwBW4kG4KsQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
eric.auger.pro-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20161108024559.GA20591-5wv7dgnIgG8@public.gmane.org>
Hi Will,
On Tue, Nov 08, 2016 at 02:45:59AM +0000, Will Deacon wrote:
> Hi all,
>
> I figured this was a reasonable post to piggy-back on for the LPC minutes
> relating to guest MSIs on arm64.
>
> On Thu, Nov 03, 2016 at 10:02:05PM -0600, Alex Williamson wrote:
> > We can always have QEMU reject hot-adding the device if the reserved
> > region overlaps existing guest RAM, but I don't even really see how we
> > advise users to give them a reasonable chance of avoiding that
> > possibility. Apparently there are also ARM platforms where MSI pages
> > cannot be remapped to support the previous programmable user/VM
> > address, is it even worthwhile to support those platforms? Does that
> > decision influence whether user programmable MSI reserved regions are
> > really a second class citizen to fixed reserved regions? I expect
> > we'll be talking about this tomorrow morning, but I certainly haven't
> > come up with any viable solutions to this. Thanks,
>
> At LPC last week, we discussed guest MSIs on arm64 as part of the PCI
> microconference. I presented some slides to illustrate some of the issues
> we're trying to solve:
>
> http://www.willdeacon.ukfsn.org/bitbucket/lpc-16/msi-in-guest-arm64.pdf
>
> Punit took some notes (thanks!) on the etherpad here:
>
> https://etherpad.openstack.org/p/LPC2016_PCI
>
> although the discussion was pretty lively and jumped about, so I've had
> to go from memory where the notes didn't capture everything that was
> said.
>
> To summarise, arm64 platforms differ in their handling of MSIs when compared
> to x86:
>
> 1. The physical memory map is not standardised (Jon pointed out that
> this is something that was realised late on)
> 2. MSIs are usually treated the same as DMA writes, in that they must be
> mapped by the SMMU page tables so that they target a physical MSI
> doorbell
> 3. On some platforms, MSIs bypass the SMMU entirely (e.g. due to an MSI
> doorbell built into the PCI RC)
> 4. Platforms typically have some set of addresses that abort before
> reaching the SMMU (e.g. because the PCI identifies them as P2P).
>
> All of this means that userspace (QEMU) needs to identify the memory
> regions corresponding to points (3) and (4) and ensure that they are
> not allocated in the guest physical (IPA) space. For platforms that can
> remap the MSI doorbell as in (2), then some space also needs to be
> allocated for that.
>
> Rather than treat these as separate problems, a better interface is to
> tell userspace about a set of reserved regions, and have this include
> the MSI doorbell, irrespective of whether or not it can be remapped.
Is my understanding correct, that you need to tell userspace about the
location of the doorbell (in the IOVA space) in case (2), because even
though the configuration of the device is handled by the (host) kernel
through trapping of the BARs, we have to avoid the VFIO user programming
the device to create other DMA transactions to this particular address,
since that will obviously conflict and either not produce the desired
DMA transactions or result in unintended weird interrupts?
Thanks,
Christoffer
^ permalink raw reply
* Re: [PATCH 1/2] iio: gyro: mpu3050: remove duplicate initializer
From: Jonathan Cameron @ 2016-11-08 20:29 UTC (permalink / raw)
To: Linus Walleij, Arnd Bergmann
Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdaZhdF5UbUp8L4aVuJmeQd2nD0+rLHXjTtJZ64d_S1hFw@mail.gmail.com>
On 08/11/16 15:39, Linus Walleij wrote:
> On Tue, Nov 8, 2016 at 2:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> The newly added mpu3050 driver has two initializations for the
>> module owner, which causes a warning for 'make W=1':
>>
>> include/linux/export.h:37:21: error: initialized field overwritten [-Werror=override-init]
>> drivers/iio/gyro/mpu3050-core.c:749:19: note: in expansion of macro 'THIS_MODULE'
>>
>> This removes one of the two.
>>
>> Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Applied to the togreg branch of iio.git. Initially pushed out as testing for the
autobuilders to play with it.
Thanks,
Jonathan
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* Re: [PATCH] staging: iio: tsl2583: fix unused function warning
From: Jonathan Cameron @ 2016-11-08 20:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Greg Kroah-Hartman, Brian Masney, Eva Rachel Retuya,
Bhumika Goyal, linux-iio, devel, linux-kernel
In-Reply-To: <20161108140213.2270755-1-arnd@arndb.de>
On 08/11/16 14:01, Arnd Bergmann wrote:
> Removing a call to the taos_chip_off() makes it unused when CONFIG_PM
> is disabled:
>
> drivers/staging/iio/light/tsl2583.c:438:12: error: ‘taos_chip_off’ defined but not used [-Werror=unused-function]
>
> This removes all the #ifdef in this file, and marks the PM functions as
> __maybe_unused instead, which is more reliable and gives us better
> compile time coverage.
>
> Fixes: 0561155f6fc5 ("staging: iio: tsl2583: don't shutdown chip when updating the lux table")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks. Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it.
thanks,
Jonathan
> ---
> drivers/staging/iio/light/tsl2583.c | 15 +++------------
> 1 file changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/iio/light/tsl2583.c b/drivers/staging/iio/light/tsl2583.c
> index 7eab17f4557e..d74e33bacbf9 100644
> --- a/drivers/staging/iio/light/tsl2583.c
> +++ b/drivers/staging/iio/light/tsl2583.c
> @@ -816,8 +816,7 @@ static int taos_probe(struct i2c_client *clientp,
> return 0;
> }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int taos_suspend(struct device *dev)
> +static int __maybe_unused taos_suspend(struct device *dev)
> {
> struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
> struct tsl2583_chip *chip = iio_priv(indio_dev);
> @@ -834,7 +833,7 @@ static int taos_suspend(struct device *dev)
> return ret;
> }
>
> -static int taos_resume(struct device *dev)
> +static int __maybe_unused taos_resume(struct device *dev)
> {
> struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
> struct tsl2583_chip *chip = iio_priv(indio_dev);
> @@ -850,10 +849,6 @@ static int taos_resume(struct device *dev)
> }
>
> static SIMPLE_DEV_PM_OPS(taos_pm_ops, taos_suspend, taos_resume);
> -#define TAOS_PM_OPS (&taos_pm_ops)
> -#else
> -#define TAOS_PM_OPS NULL
> -#endif
>
> static struct i2c_device_id taos_idtable[] = {
> { "tsl2580", 0 },
> @@ -863,7 +858,6 @@ static struct i2c_device_id taos_idtable[] = {
> };
> MODULE_DEVICE_TABLE(i2c, taos_idtable);
>
> -#ifdef CONFIG_OF
> static const struct of_device_id taos2583_of_match[] = {
> { .compatible = "amstaos,tsl2580", },
> { .compatible = "amstaos,tsl2581", },
> @@ -871,15 +865,12 @@ static const struct of_device_id taos2583_of_match[] = {
> { },
> };
> MODULE_DEVICE_TABLE(of, taos2583_of_match);
> -#else
> -#define taos2583_of_match NULL
> -#endif
>
> /* Driver definition */
> static struct i2c_driver taos_driver = {
> .driver = {
> .name = "tsl2583",
> - .pm = TAOS_PM_OPS,
> + .pm = &taos_pm_ops,
> .of_match_table = taos2583_of_match,
> },
> .id_table = taos_idtable,
>
^ permalink raw reply
* Finding EPT entries for nested guest in L0
From: Rohith Kugve Raghavendra @ 2016-11-08 20:27 UTC (permalink / raw)
To: kvm
I have 2 questions.
1. In nested VMs that use multi-dimensional page tables( EPT on EPT)
where exactly in the code are EPT ( 0 -> 2) entries constructed? I can
know from the Turtles paper that these entries are created by
combining EPT 1->2 and EPT 0->1. But I can find that in KVM code.
2. Are there rmap entries for EPT 0->2 pages maintained? I am trying
to write protect nested guest GFN's directly in L0 ( without letting
L1 do it) but I don't know how to find the EPT 0->2 entry for a given
L2 guest GFN.
regards,
Rohith
^ permalink raw reply
* Re: A way to reduce compression overhead
From: Sage Weil @ 2016-11-08 20:27 UTC (permalink / raw)
To: Igor Fedotov; +Cc: ceph-devel
In-Reply-To: <828b8988-5c29-8ec3-be00-e6c45fa15ab0@mirantis.com>
On Tue, 8 Nov 2016, Igor Fedotov wrote:
> Hi Sage, et al.
>
> Let me share some ideas about possible compression burden reduction on the
> cluster.
>
> As known we perform block compression at BlueStore level for each replica
> independently. This triples compression CPU overhead for the cluster. Looks
> like significant CPU resource waste IMHO.
>
> We can probably eliminate this overhead by introduction write request
> preprocessing performed at ObjectStore level synchronously. This preprocessing
> parses transaction, detects write requests and transforms them into different
> ones aligned with current store allocation unit. At the same time resulting
> extents that span more than single AU are compressed if needed. I.e.
> preprocessing do some of the job performed at BlueStore::_do_write_data that
> splits write request into _do_write_small/_do_write_big calls. But after the
> split and big blob compression preprocessor simply updates the transaction
> with new write requests.
>
> E.g.
>
> with AU = 0x1000
>
> Write Request (1~0xffff) is transformed into the following sequence:
>
> WriteX 1~0xfff (uncompressed)
>
> WriteX 0x1000~E000 (compressed if needed)
>
> WriteX 0xf000~0xfff (uncompressed)
>
> Then updated transaction is passed to all replicas including the master one
> using regular apply_/queue_transaction mechanics.
>
>
> As a bonus one receives automatic payload compression when transporting
> request to remote store replicas.
> Regular write request path should be preserved for EC pools and other needs as
> well.
>
> Please note that almost no latency is introduced for request handling.
> Replicas receive modified transaction later but they do not spend time on
> doing split/compress stuff.
I think this is pretty reasonable! We have a couple options... we could
(1) just expose a compression alignment via ObjectStore, (2) take
compression alignment from a pool property, or (3) have an explicit
per-write call into ObjectStore so that it can chunk it up however it
likes.
Whatever we choose, the tricky bit is that there may be different stores
on different replicas. Or we could let the primary just decide locally,
given that this is primarily an optimization; in the worst case we
compress something on the primary but one replica doesn't support
compression and just decompresses it before doing the write (i.e., we get
on-the-wire compression but no on-disk compression).
I lean toward the simplicity of get_compression_alignment() and
get_compression_alg() (or similar) and just make a local (primary)
decision. Then we just have a simple compatibility write_compressed()
implementation (or helper) that decompresses the payload so that we can do
a normal write.
Before getting to carried away, though, we should consider whether we're
going to want to take a further step to allow clients to compress data
before it's sent. That isn't necessarily in conflict with this if we go
with pool properties to inform the alignment and compression alg
decision. If we assume that the ObjectStore on the primary gets to decide
everything it will work less well...
> There is a potential conflict with the current garbage collection stuff though
> - we can't perform GC during preprocessing due to possible race with preceding
> unfinished transactions and consequently we're unable to merge and compress
> merged data. Well, we can do that when applying transaction but this will
> produce a sequence like this at each replica:
>
> decompress original request + decompress data to merge -> compress merged
> data.
>
> Probably this limitation isn't that bad - IMHO it's better to have compressed
> blobs aligned with original write requests.
>
> Moreover I have some ideas how to get rid of blob_depth notion that makes life
> a bit easier. Will share shortly.
I'm curious what you have in mind! The blob_depth as currently
implemented is not terribly reliable...
sage
^ permalink raw reply
* [PATCH RFC 4/4] xfs: implement basic COW fork speculative preallocation
From: Brian Foster @ 2016-11-08 20:27 UTC (permalink / raw)
To: linux-xfs
In-Reply-To: <1478636856-7590-1-git-send-email-bfoster@redhat.com>
COW fork preallocation is currently limited to what is specified by the
COW extent size hint, which is typically much less aggressive than
traditional speculative preallocation added when sufficiently large
files are extended. This type of algorithm is not relevant for COW
reservation since by design, COW reservation never involves extending
the size of a file.
That said, we can be more aggressive with COW fork preallocation given
that we have extended the same inode tagging and reclaim infrastructure
used for post-eof preallocation to support COW fork preallocation. This
provides the ability to reclaim COW fork preallocation in the background
or on demand.
As such, add a simple COW fork speculative preallocation algorithm that
extends COW fork reservations due to file writes out to the next data
fork extent, unshared boundary or the next preexisting extent in the COW
fork, whichever limit we hit first. This provides a prealloc algorithm
that, like post-eof speculative preallocation, is based on the size of
preexisting extents.
XXX: This requires refinements such as throttling, reclaim, etc., as
noted in the comments.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/xfs/xfs_iomap.c | 48 +++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 45 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 40bf66c..43936aa 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -540,8 +540,11 @@ xfs_file_iomap_begin_delay(
struct xfs_bmbt_irec got;
struct xfs_bmbt_irec prev;
struct xfs_bmbt_irec imap; /* for iomap */
+ struct xfs_bmbt_irec drec; /* raw data fork record */
xfs_extnum_t idx;
int fork = XFS_DATA_FORK;
+ bool shared;
+ bool trimmed;
ASSERT(!XFS_IS_REALTIME_INODE(ip));
ASSERT(!xfs_get_extsz_hint(ip));
@@ -574,11 +577,9 @@ xfs_file_iomap_begin_delay(
*/
xfs_bmap_search_extents(ip, offset_fsb, XFS_DATA_FORK, &eof, &idx,
&got, &prev);
- imap = got;
+ drec = imap = got;
if (!eof && got.br_startoff <= offset_fsb) {
if (xfs_is_reflink_inode(ip)) {
- bool shared, trimmed;
-
/*
* Assume the data extent is shared if an extent exists
* in the cow fork.
@@ -651,6 +652,47 @@ xfs_file_iomap_begin_delay(
end_fsb = min(end_fsb, maxbytes_fsb);
ASSERT(end_fsb > offset_fsb);
}
+ } else if (fork == XFS_COW_FORK && !trimmed) {
+ struct xfs_bmbt_irec tmp = drec;
+ xfs_extlen_t len;
+
+ /*
+ * If we get here, we have a shared data extent without a COW
+ * fork reservation and the range of the write doesn't cross an
+ * unshared boundary. To implement COW fork preallocation,
+ * allocate as much as possible up until the next data fork
+ * extent, the next data fork unshared boundary or the next
+ * existing extent in the COW fork.
+ */
+ ASSERT(shared && offset_fsb >= tmp.br_startoff);
+
+ /*
+ * Trim the original data fork extent to the start of the write
+ * and the next unshared boundary. This defines the maximum COW
+ * fork preallocation. bmapi_reserve_delalloc() will trim to the
+ * next COW fork extent (got) if one exists.
+ */
+ len = tmp.br_blockcount - (offset_fsb - tmp.br_startoff);
+ xfs_trim_extent(&tmp, offset_fsb, len);
+ error = xfs_reflink_trim_around_shared(ip, &tmp, &shared,
+ &trimmed);
+ if (error)
+ goto out_unlock;
+ ASSERT(shared);
+ end_fsb = tmp.br_startoff + tmp.br_blockcount;
+
+ /*
+ * TODO:
+ * - Throttling based on low free space conditions (try to
+ * refactor into xfs_iomap_prealloc_size()).
+ * - Associated scan/reclaim mechanism on buffered write ENOSPC.
+ * - Alignment? Might not want to overlap unshared blocks.
+ * bmapi_reserve_delalloc() might do this anyways due to
+ * cowextszhint.
+ * - Adopt similar cowextsz hint behavior as for traditional
+ * extsz hint? E.g., cowextsz hint overrides prealloc?
+ * - allocsize mount option?
+ */
}
retry:
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 1/4] xfs: clean up cow fork reservation and tag inodes correctly
From: Brian Foster @ 2016-11-08 20:27 UTC (permalink / raw)
To: linux-xfs
In-Reply-To: <1478636856-7590-1-git-send-email-bfoster@redhat.com>
COW fork reservation is implemented via delayed allocation. The code is
modeled after the traditional delalloc allocation code, but is slightly
different in terms of how preallocation occurs. Rather than post-eof
speculative preallocation, COW fork preallocation is implemented via a
COW extent size hint that is designed to minimize fragmentation as a
reflinked file is split over time.
xfs_reflink_reserve_cow() still uses logic that is oriented towards
dealing with post-eof speculative preallocation, however, and is stale
or not necessarily correct. First, the EOF alignment to the COW extent
size hint is implemented in xfs_bmapi_reserve_delalloc() (which does so
correctly by aligning the start and end offsets) and so is not necessary
in xfs_reflink_reserve_cow(). The backoff and retry logic on ENOSPC is
also ineffective for the same reason, as xfs_bmapi_reserve_delalloc()
will simply perform the same allocation request on the retry. Finally,
since the COW extent size hint aligns the start and end offset of the
range to allocate, the end_fsb != orig_end_fsb logic is not sufficient.
Indeed, if a write request happens to end on an aligned offset, it is
possible that we do not tag the inode for COW preallocation even though
xfs_bmapi_reserve_delalloc() may have preallocated at the start offset.
Kill the unnecessary, duplicate code in xfs_reflink_reserve_cow() and
update the preallocation tag logic to check whether the bmap allocation
actually matches the range that was requested.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/xfs/xfs_reflink.c | 28 ++++------------------------
1 file changed, 4 insertions(+), 24 deletions(-)
diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
index a279b4e..b19a7e0 100644
--- a/fs/xfs/xfs_reflink.c
+++ b/fs/xfs/xfs_reflink.c
@@ -244,11 +244,9 @@ xfs_reflink_reserve_cow(
bool *shared)
{
struct xfs_bmbt_irec got, prev;
- xfs_fileoff_t end_fsb, orig_end_fsb;
int eof = 0, error = 0;
bool trimmed;
xfs_extnum_t idx;
- xfs_extlen_t align;
/*
* Search the COW fork extent list first. This serves two purposes:
@@ -285,32 +283,14 @@ xfs_reflink_reserve_cow(
if (error)
return error;
- end_fsb = orig_end_fsb = imap->br_startoff + imap->br_blockcount;
- align = xfs_eof_alignment(ip, xfs_get_cowextsz_hint(ip));
- if (align)
- end_fsb = roundup_64(end_fsb, align);
-
-retry:
error = xfs_bmapi_reserve_delalloc(ip, XFS_COW_FORK, imap->br_startoff,
- end_fsb - imap->br_startoff, &got, &prev, &idx, eof);
- switch (error) {
- case 0:
- break;
- case -ENOSPC:
- case -EDQUOT:
- /* retry without any preallocation */
- trace_xfs_reflink_cow_enospc(ip, imap);
- if (end_fsb != orig_end_fsb) {
- end_fsb = orig_end_fsb;
- goto retry;
- }
- /*FALLTHRU*/
- default:
+ imap->br_blockcount, &got, &prev, &idx, eof);
+ if (error)
return error;
- }
- if (end_fsb != orig_end_fsb)
+ if (imap->br_startoff != got.br_startoff ||
+ imap->br_blockcount != got.br_blockcount)
xfs_inode_set_cowblocks_tag(ip);
trace_xfs_reflink_cow_alloc(ip, &got);
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 3/4] xfs: reuse xfs_file_iomap_begin_delay() for cow fork delalloc
From: Brian Foster @ 2016-11-08 20:27 UTC (permalink / raw)
To: linux-xfs
In-Reply-To: <1478636856-7590-1-git-send-email-bfoster@redhat.com>
COW fork reservation (delayed allocation) is implemented in
xfs_reflink_reserve_cow() and is generally based on the traditional data
fork delalloc logic in xfs_file_iomap_begin_delay(). In preparation for
further changes to implement more aggressive COW fork preallocation,
refactor the COW reservation code to reuse xfs_file_iomap_begin_delay()
for data fork allocation or COW fork reservation. This patch does not
change behavior.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/xfs/xfs_iomap.c | 79 +++++++++++++++++++++++++++++++++++++++---------------
1 file changed, 58 insertions(+), 21 deletions(-)
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 7446531..40bf66c 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -532,7 +532,7 @@ xfs_file_iomap_begin_delay(
struct xfs_inode *ip = XFS_I(inode);
struct xfs_mount *mp = ip->i_mount;
struct xfs_ifork *ifp = XFS_IFORK_PTR(ip, XFS_DATA_FORK);
- xfs_fileoff_t offset_fsb = XFS_B_TO_FSBT(mp, offset);
+ xfs_fileoff_t offset_fsb;
xfs_fileoff_t maxbytes_fsb =
XFS_B_TO_FSB(mp, mp->m_super->s_maxbytes);
xfs_fileoff_t end_fsb, orig_end_fsb;
@@ -541,10 +541,14 @@ xfs_file_iomap_begin_delay(
struct xfs_bmbt_irec prev;
struct xfs_bmbt_irec imap; /* for iomap */
xfs_extnum_t idx;
+ int fork = XFS_DATA_FORK;
ASSERT(!XFS_IS_REALTIME_INODE(ip));
ASSERT(!xfs_get_extsz_hint(ip));
+ offset_fsb = XFS_B_TO_FSBT(mp, offset);
+ end_fsb = min(XFS_B_TO_FSB(mp, offset + count), maxbytes_fsb);
+
xfs_ilock(ip, XFS_ILOCK_EXCL);
if (unlikely(XFS_TEST_ERROR(
@@ -564,23 +568,50 @@ xfs_file_iomap_begin_delay(
goto out_unlock;
}
+ /*
+ * Search for a preexisting extent. COW fork allocation may still be
+ * required for reflink inodes if the data extent is shared.
+ */
xfs_bmap_search_extents(ip, offset_fsb, XFS_DATA_FORK, &eof, &idx,
&got, &prev);
imap = got;
if (!eof && got.br_startoff <= offset_fsb) {
if (xfs_is_reflink_inode(ip)) {
- bool shared;
+ bool shared, trimmed;
- end_fsb = min(XFS_B_TO_FSB(mp, offset + count),
- maxbytes_fsb);
- xfs_trim_extent(&imap, offset_fsb, end_fsb - offset_fsb);
- error = xfs_reflink_reserve_cow(ip, &imap, &shared);
+ /*
+ * Assume the data extent is shared if an extent exists
+ * in the cow fork.
+ */
+ xfs_trim_extent(&imap, offset_fsb,
+ end_fsb - offset_fsb);
+ xfs_bmap_search_extents(ip, imap.br_startoff,
+ XFS_COW_FORK, &eof, &idx, &got, &prev);
+ if (!eof && got.br_startoff <= imap.br_startoff) {
+ trace_xfs_reflink_cow_found(ip, &got);
+ xfs_trim_extent(&imap, got.br_startoff,
+ got.br_blockcount);
+ goto done;
+ }
+
+ /*
+ * No existing cow fork extent. Now we have to actually
+ * check if the data extent is shared and trim the
+ * mapping to the next (un)shared boundary.
+ */
+ error = xfs_reflink_trim_around_shared(ip, &imap,
+ &shared, &trimmed);
if (error)
goto out_unlock;
+ if (!shared)
+ goto done;
+
+ end_fsb = imap.br_startoff + imap.br_blockcount;
+ fork = XFS_COW_FORK;
+ } else {
+ trace_xfs_iomap_found(ip, offset, count, 0, &imap);
+ goto done;
}
-
- trace_xfs_iomap_found(ip, offset, count, 0, &imap);
- goto done;
}
error = xfs_qm_dqattach_locked(ip, 0);
@@ -597,10 +628,10 @@ xfs_file_iomap_begin_delay(
* the lower level functions are updated.
*/
count = min_t(loff_t, count, 1024 * PAGE_SIZE);
- end_fsb = orig_end_fsb =
- min(XFS_B_TO_FSB(mp, offset + count), maxbytes_fsb);
+ end_fsb = orig_end_fsb = min(XFS_B_TO_FSB(mp, offset + count), end_fsb);
+ xfs_trim_extent(&imap, offset_fsb, end_fsb - offset_fsb);
- if (eof) {
+ if (eof && fork == XFS_DATA_FORK) {
xfs_fsblock_t prealloc_blocks;
prealloc_blocks =
@@ -623,9 +654,8 @@ xfs_file_iomap_begin_delay(
}
retry:
- error = xfs_bmapi_reserve_delalloc(ip, XFS_DATA_FORK, offset_fsb,
- end_fsb - offset_fsb, &got,
- &prev, &idx, eof);
+ error = xfs_bmapi_reserve_delalloc(ip, fork, offset_fsb,
+ end_fsb - offset_fsb, &got, &prev, &idx, eof);
switch (error) {
case 0:
break;
@@ -643,14 +673,21 @@ xfs_file_iomap_begin_delay(
}
/*
- * Tag the inode as speculatively preallocated so we can reclaim this
- * space on demand, if necessary.
+ * Tag the inode if we've added post-eof or cow fork preallocation so we
+ * can reclaim this space on demand.
*/
- if (end_fsb != orig_end_fsb)
- xfs_inode_set_eofblocks_tag(ip);
+ if (fork == XFS_DATA_FORK) {
+ trace_xfs_iomap_alloc(ip, offset, count, 0, &got);
+ if (end_fsb != orig_end_fsb)
+ xfs_inode_set_eofblocks_tag(ip);
+ imap = got;
+ } else {
+ trace_xfs_reflink_cow_alloc(ip, &got);
+ if (got.br_startblock != offset_fsb ||
+ got.br_blockcount != end_fsb - offset_fsb)
+ xfs_inode_set_cowblocks_tag(ip);
+ }
- trace_xfs_iomap_alloc(ip, offset, count, 0, &got);
- imap = got;
done:
if (isnullstartblock(imap.br_startblock))
imap.br_startblock = DELAYSTARTBLOCK;
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 2/4] xfs: logically separate iomap range from allocation range
From: Brian Foster @ 2016-11-08 20:27 UTC (permalink / raw)
To: linux-xfs
In-Reply-To: <1478636856-7590-1-git-send-email-bfoster@redhat.com>
The xfs_file_iomap_begin_delay() function currently converts the bmbt
record output from the xfs_bmapi_reserve_delalloc() call to the iomap
mapping for the higher level iomap code. In preparation to reuse
xfs_file_iomap_begin_delay() for data fork and COW fork allocation,
logically separate the iomap mapping provided to the caller from the
bmbt record returned by xfs_bmapi_reserve_delalloc().
This is necessary because while COW reservation involves delalloc
allocation to the COW fork, the mapping returned to the caller must
still refer to the shared blocks from the data fork. Note that this
patch does not change behavior in any way.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/xfs/xfs_iomap.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 193aee4..7446531 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -539,6 +539,7 @@ xfs_file_iomap_begin_delay(
int error = 0, eof = 0;
struct xfs_bmbt_irec got;
struct xfs_bmbt_irec prev;
+ struct xfs_bmbt_irec imap; /* for iomap */
xfs_extnum_t idx;
ASSERT(!XFS_IS_REALTIME_INODE(ip));
@@ -565,19 +566,20 @@ xfs_file_iomap_begin_delay(
xfs_bmap_search_extents(ip, offset_fsb, XFS_DATA_FORK, &eof, &idx,
&got, &prev);
+ imap = got;
if (!eof && got.br_startoff <= offset_fsb) {
if (xfs_is_reflink_inode(ip)) {
bool shared;
end_fsb = min(XFS_B_TO_FSB(mp, offset + count),
maxbytes_fsb);
- xfs_trim_extent(&got, offset_fsb, end_fsb - offset_fsb);
- error = xfs_reflink_reserve_cow(ip, &got, &shared);
+ xfs_trim_extent(&imap, offset_fsb, end_fsb - offset_fsb);
+ error = xfs_reflink_reserve_cow(ip, &imap, &shared);
if (error)
goto out_unlock;
}
- trace_xfs_iomap_found(ip, offset, count, 0, &got);
+ trace_xfs_iomap_found(ip, offset, count, 0, &imap);
goto done;
}
@@ -648,17 +650,18 @@ xfs_file_iomap_begin_delay(
xfs_inode_set_eofblocks_tag(ip);
trace_xfs_iomap_alloc(ip, offset, count, 0, &got);
+ imap = got;
done:
- if (isnullstartblock(got.br_startblock))
- got.br_startblock = DELAYSTARTBLOCK;
+ if (isnullstartblock(imap.br_startblock))
+ imap.br_startblock = DELAYSTARTBLOCK;
- if (!got.br_startblock) {
- error = xfs_alert_fsblock_zero(ip, &got);
+ if (!imap.br_startblock) {
+ error = xfs_alert_fsblock_zero(ip, &imap);
if (error)
goto out_unlock;
}
- xfs_bmbt_to_iomap(ip, iomap, &got);
+ xfs_bmbt_to_iomap(ip, iomap, &imap);
out_unlock:
xfs_iunlock(ip, XFS_ILOCK_EXCL);
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 0/4] xfs: basic cow fork speculative preallocation
From: Brian Foster @ 2016-11-08 20:27 UTC (permalink / raw)
To: linux-xfs
Hi all,
This is an experiment based on an idea for COW fork speculative
preallocation. This is experimental, lightly/barely tested and sent in
RFC form to solicit thoughts, ideas or flames before I spend time taking
it further.
Patch 1 probably stands on its own. Patches 2 and 3 are some refactoring
and patch 4 implements the basic idea, which is described in the commit
log description. The testing I've done so far is basically similar to
how one would test the effects of traditional speculative preallocation:
write to multiple reflinked files in parallel and examine the resulting
fragmentation. Specifically, I wrote sequentially to 16 different
reflinked files of the same 8GB original (which has two data extents,
completely shared). Without preallocation, the test results in ~248
extents across the 16 files. With preallocation, the test results in 32
extents across the 16 files (i.e., 2 extents per file, same as the
source file).
An obvious tradeoff is the unnecessarily aggressive allocation that
might occur in the event of random writes to a large file (such as in
the cloned VM disk image use case), but my thinking is that the
cowblocks tagging and reclaim infrastructure should manage that
sufficiently (lack of testing notwithstanding). In any event, I'm
interested in any thoughts along the lines of whether this is useful at
all, alternative algorithm ideas, etc.
Brian
Brian Foster (4):
xfs: clean up cow fork reservation and tag inodes correctly
xfs: logically separate iomap range from allocation range
xfs: reuse xfs_file_iomap_begin_delay() for cow fork delalloc
xfs: implement basic COW fork speculative preallocation
fs/xfs/xfs_iomap.c | 132 +++++++++++++++++++++++++++++++++++++++++----------
fs/xfs/xfs_reflink.c | 28 ++---------
2 files changed, 111 insertions(+), 49 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v11 15/22] vfio: Introduce vfio_set_irqs_validate_and_prepare()
From: Kirti Wankhede @ 2016-11-08 20:22 UTC (permalink / raw)
To: Alexey Kardashevskiy, alex.williamson, pbonzini, kraxel, cjia
Cc: qemu-devel, kvm, kevin.tian, jike.song, bjsdjshi, linux-kernel
In-Reply-To: <dd3c9f16-e0fc-fc81-e151-48eab6759070@ozlabs.ru>
On 11/8/2016 2:16 PM, Alexey Kardashevskiy wrote:
> On 05/11/16 08:10, Kirti Wankhede wrote:
>> Vendor driver using mediated device framework would use same mechnism to
>> validate and prepare IRQs. Introducing this function to reduce code
>> replication in multiple drivers.
>>
>> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
>> Signed-off-by: Neo Jia <cjia@nvidia.com>
>> Change-Id: Ie201f269dda0713ca18a07dc4852500bd8b48309
>> ---
>> drivers/vfio/vfio.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/vfio.h | 4 ++++
>> 2 files changed, 52 insertions(+)
>>
>> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
>> index 9a03be0942a1..ed2361e4b904 100644
>> --- a/drivers/vfio/vfio.c
>> +++ b/drivers/vfio/vfio.c
>> @@ -1858,6 +1858,54 @@ int vfio_info_add_capability(struct vfio_info_cap *caps, int cap_type_id,
>> }
>> EXPORT_SYMBOL(vfio_info_add_capability);
>>
>> +int vfio_set_irqs_validate_and_prepare(struct vfio_irq_set *hdr, int num_irqs,
>> + int max_irq_type, size_t *data_size)
>> +{
>> + unsigned long minsz;
>> + size_t size;
>> +
>> + minsz = offsetofend(struct vfio_irq_set, count);
>> +
>> + if ((hdr->argsz < minsz) || (hdr->index >= max_irq_type) ||
>> + (hdr->count >= (U32_MAX - hdr->start)) ||
>> + (hdr->flags & ~(VFIO_IRQ_SET_DATA_TYPE_MASK |
>> + VFIO_IRQ_SET_ACTION_TYPE_MASK)))
>> + return -EINVAL;
>> +
>> + if (data_size)
>
> Pointless check, the callers will pass non null pointer with value
> initialized to 0 anyway.
>
Not always, When VFIO_IRQ_SET_DATA_NONE flag is set, caller can pass
data_size = NULL.
>
>> + *data_size = 0;
>> +
>> + if (hdr->start >= num_irqs || hdr->start + hdr->count > num_irqs)
>> + return -EINVAL;
>> +
>> + switch (hdr->flags & VFIO_IRQ_SET_DATA_TYPE_MASK) {
>> + case VFIO_IRQ_SET_DATA_NONE:
>> + size = 0;
>> + break;
>> + case VFIO_IRQ_SET_DATA_BOOL:
>> + size = sizeof(uint8_t);
>> + break;
>> + case VFIO_IRQ_SET_DATA_EVENTFD:
>> + size = sizeof(int32_t);
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + if (size) {
>
> The whole branch would even work for size == 0.
>
In that case below check (!data_size) might result in error if data_size
== NULL, whereas its not error case when size == 0, i.e.
VFIO_IRQ_SET_DATA_NONE flag set.
>> + if (hdr->argsz - minsz < hdr->count * size)
>> + return -EINVAL;
>> +
>> + if (!data_size)
>> + return -EINVAL;
>
> Redundant check as well.
>
This is not redundant. If you see above check, it sets its init value to
0 but doesn't fail.
>> +
>> + *data_size = hdr->count * size;
>> + }
>> +
>> + return 0;
>> +}
>
> It does not really prepare anything as the name suggests. It looks like
> this is 2 different helpers actually:
>
> int vfio_set_irqs_validate()
> and
> size_t vfio_set_irqs_hdr_to_data_size()
>
Later one is the prepare.
>
> And it would make it easier to review/bisect if 16/22 and 17/22 were merged
> into this one as this patch alone adds new code which it does not use and
> all 3 patches are fairly small.
>
I do had all 3 patch merged in one in earlier version of patchset. This
is split as per Alex's suggestion.
>
>> +EXPORT_SYMBOL(vfio_set_irqs_validate_and_prepare);
>
> Everything you export in this patchset is EXPORT_SYMBOL() while the
> existing code uses EXPORT_SYMBOL_GPL(), is this for a reason?
>
>
We want these symbols to be available to all drivers.
Thanks,
Kirti
>> +
>> /*
>> * Pin a set of guest PFNs and return their associated host PFNs for local
>> * domain only.
>> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
>> index cf90393a11e2..87c9afecd822 100644
>> --- a/include/linux/vfio.h
>> +++ b/include/linux/vfio.h
>> @@ -116,6 +116,10 @@ extern void vfio_info_cap_shift(struct vfio_info_cap *caps, size_t offset);
>> extern int vfio_info_add_capability(struct vfio_info_cap *caps,
>> int cap_type_id, void *cap_type);
>>
>> +extern int vfio_set_irqs_validate_and_prepare(struct vfio_irq_set *hdr,
>> + int num_irqs, int max_irq_type,
>> + size_t *data_size);
>> +
>> struct pci_dev;
>> #ifdef CONFIG_EEH
>> extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
>>
>
>
^ permalink raw reply
* Re: [PATCH v4 0/2] ARC: Set of patches for IRQ subsystem
From: Vineet Gupta @ 2016-11-08 20:25 UTC (permalink / raw)
To: Yuriy Kolerov, linux-snps-arc@lists.infradead.org
Cc: Alexey.Brodkin@synopsys.com, tglx@linutronix.de,
linux-kernel@vger.kernel.org
In-Reply-To: <1478588912-3991-1-git-send-email-yuriy.kolerov@synopsys.com>
On 11/07/2016 11:08 PM, Yuriy Kolerov wrote:
> The first patch fixes misuse of IRQ numbers. In some places of the
> Linux kernel for ARC hardware IRQ numbers are used as virtual IRQ
> numbers and obviously it is wrong.
>
> The second patch forces the kernel to set a simple distribution mode
> for common interrupts in cases when such interrupts are routed to a
> single core.
>
> Yuriy Kolerov (2):
> ARC: IRQ: Do not use hwirq as virq and vice versa
> ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination
> core
>
> arch/arc/include/asm/smp.h | 4 ++--
> arch/arc/kernel/mcip.c | 33 ++++++++++++++++++++-------------
> arch/arc/kernel/smp.c | 13 +++++++++----
> 3 files changed, 31 insertions(+), 19 deletions(-)
Thx Yuriy.
Added to for-curr !
-Vineet
^ permalink raw reply
* [PATCH v4 0/2] ARC: Set of patches for IRQ subsystem
From: Vineet Gupta @ 2016-11-08 20:25 UTC (permalink / raw)
To: linux-snps-arc
In-Reply-To: <1478588912-3991-1-git-send-email-yuriy.kolerov@synopsys.com>
On 11/07/2016 11:08 PM, Yuriy Kolerov wrote:
> The first patch fixes misuse of IRQ numbers. In some places of the
> Linux kernel for ARC hardware IRQ numbers are used as virtual IRQ
> numbers and obviously it is wrong.
>
> The second patch forces the kernel to set a simple distribution mode
> for common interrupts in cases when such interrupts are routed to a
> single core.
>
> Yuriy Kolerov (2):
> ARC: IRQ: Do not use hwirq as virq and vice versa
> ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination
> core
>
> arch/arc/include/asm/smp.h | 4 ++--
> arch/arc/kernel/mcip.c | 33 ++++++++++++++++++++-------------
> arch/arc/kernel/smp.c | 13 +++++++++----
> 3 files changed, 31 insertions(+), 19 deletions(-)
Thx Yuriy.
Added to for-curr !
-Vineet
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.