* Re: [PATCH 1/2] ASoC: Allow drivers to specify how many bits are significant on a DAI
From: Peter Ujfalusi @ 2012-01-17 8:55 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, patches, Liam Girdwood
In-Reply-To: <1326739267-9678-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On 01/16/2012 07:41 PM, Mark Brown wrote:
> /*
> + * List of sample sizes that might go over the bus for parameter
> + * application. There ought to be a wildcard sample size for things
> + * like the DAC/ADC resolution to use but there isn't right now.
> + */
> +static int sample_sizes[] = {
> + 8, 16, 24, 32,
> +};
> +
> +static void soc_pcm_apply_msb(struct snd_pcm_substream *substream,
> + struct snd_soc_dai *dai)
> +{
> + int ret, i, bits;
> +
> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> + bits = dai->driver->playback.sig_bits;
> + else
> + bits = dai->driver->capture.sig_bits;
> +
> + if (!bits)
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(sample_sizes); i++) {
> + ret = snd_pcm_hw_constraint_msbits(substream->runtime,
> + 0, sample_sizes[i],
> + bits);
Should we apply the constraint only if the sample size is bigger than
the msbit request:
if (sample_sizes[i] > bits) {
ret = snd_pcm_hw_constraint_msbits();
}
Might be not an issue to say that we have 24msbit on the 8bit sample,
but it does not sound right.
> + if (ret != 0)
> + dev_warn(dai->dev,
> + "Failed to set MSB %d/%d: %d\n",
> + bits, sample_sizes[i], ret);
> + }
> +}
> +
> +/*
> * Called by ALSA when a PCM substream is opened, the runtime->hw record is
> * then initialized and any private data can be allocated. This also calls
> * startup for the cpu DAI, platform, machine and codec DAI.
> @@ -187,6 +220,9 @@ static int soc_pcm_open(struct snd_pcm_substream *substream)
> goto config_err;
> }
>
> + soc_pcm_apply_msb(substream, codec_dai);
> + soc_pcm_apply_msb(substream, cpu_dai);
> +
> /* Symmetry only applies if we've already got an active stream. */
> if (cpu_dai->active) {
> ret = soc_pcm_apply_symmetry(substream, cpu_dai);
--
Péter
^ permalink raw reply
* Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
From: Joe Woodward @ 2012-01-17 8:54 UTC (permalink / raw)
To: Shilimkar, Santosh, Russell King - ARM Linux
Cc: linux-omap, linux-arm, Catalin Marinas
In-Reply-To: <CAMQu2gzPGrbBd4_SOM0TFfGH_Y+XYzoh2XjsoPgpzU10tFOpYQ@mail.gmail.com>
...snip...
> >
> Fair point. It will be harder to maintain and won't be consistent.
>
> >> Am not sure what you mean because secure API
> >> as such isn't a problem. If you mean one standard interface
> >> for all the ARM SOC's then that's something won't be
> >> easy to handled because it is tied up the security architecture
> >> which can vary across SoCs.
> >
> > The latter. This is exactly the kind of pain I forsaw with this
> security
> > shite, and when I heard about it I was utterly dismayed at ARM Ltd
> for
> > coming up with such a brain-dead lack of design here.
> >
> > You're having to struggle with the results of that by having lots of
> > SoC specific hooks all around the place to fiddle with this that and
> the
> > other. Your need to have something called from the early assembly
> code
> > is just yet more of that disease caused by ARM Ltd's lack of forsight
> > on this matter.
> >
> > I have no solution for you on this
>
> I managed use some secure macro kind of code but as you said it
> will be really hard to maintain.
>
> So we are stuck with this issue then.
So, is the upshot of this that the kernel isn't going to be in a position to enable the L2/outer cache on OMAP3 (due to the need for hacky/unmaintainable code)?
Hence the bootloader/uBoot had better leave it enabled...
Cheers,
Joe
>
> Regards
> Santosh
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 trivial-cleanup] tty: remove unused tty_driver->termios_locked
From: Konstantin Khlebnikov @ 2012-01-17 8:54 UTC (permalink / raw)
To: Greg Kroah-Hartman, Alan Cox; +Cc: Linus Torvalds, linux-kernel
This field is unused since v2.6.27-3221-gfe6e29f
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
---
include/linux/tty_driver.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/linux/tty_driver.h b/include/linux/tty_driver.h
index ecdaeb9..5cf6850 100644
--- a/include/linux/tty_driver.h
+++ b/include/linux/tty_driver.h
@@ -312,7 +312,6 @@ struct tty_driver {
*/
struct tty_struct **ttys;
struct ktermios **termios;
- struct ktermios **termios_locked;
void *driver_state;
/*
^ permalink raw reply related
* [Buildroot] mesa gles2 under buildroot
From: Ozgun @ 2012-01-17 8:53 UTC (permalink / raw)
To: buildroot
The configuration options --enable-gles1, --enable-gles2 are valid above
mesa 7.10.1.
So I incresed the mesa version form mesa.mk.
But now mesa gives import libxml2 error on python.
I chose the python and libxml2 packages as well. But the default libxml2
package package configuation has a --without-python option. So that it
doesn't compile libxml2 python packages.
Then I switched them to --with-python on libxml2.mk file.
But still libxml2 python libraries are absent.
How can I add libxml2 python libraries?
Eventually ;
I need a QT with 3D library.
QT needs QtOpenGl.
QtOpenGl needs opengl es2
opengl es comes with mesa3d 7.10.1.
mesa3d 7.10.1 needs xorg
mesa3d 7.10.1 needs libxml2 python.
libxml2 python --->
.....
...
..
.
Date: Thu, 12 Jan 2012 10:36:35 +0200
> From: Ozgun <ozgun.gunay@gmail.com>
> To: undisclosed-recipients:;
> Subject: [Buildroot] mesa gles2 under buildroot
> Message-ID:
> <CAPeX=+soNee6absBROUkCUUkWC_OLXURB1D_kqE5mq6Thray8Q@mail.gmail.com
> >
> Content-Type: text/plain; charset="utf-8"
>
> I'm trying to use QT with opengl support.
> The opengl comes with mesa, and mesa comes with xorg.
> I select them from buildroot configuration.
> The buildroot created rootfs successfully without opengl es support.
> libGL and libGLU files are exist but the libGLES_CM and the libGLESv2
> files (which are the essential files for QT opengl) are absent.
> Then I examined the mesa config.log file;
>
> --------
> $ ./configure --target=i686-linux --host=i686-linux
> --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr
> --sysconfdir=/etc --disable-gtk-doc --disable-nls --disable-ipv6
> --enable-egl --enable-glu --disable-glw --disable-glut --enable-gles1
> --enable-gles2 --disable-gallium --with-driver=dri
> --with-dri-drivers=swrast --disable-static
>
>
> configure:9068: WARNING: unrecognized options: --disable-gtk-doc,
> --disable-nls, --disable-ipv6, --enable-gles1, --enable-gles2
>
> --------
>
> Why the mesa doesn't recognize --enable-gles2 option?
>
>
> Also I tried to configure mesa from mesa3d.mk file under buildroot, but
> buildroot still uses the above options.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.busybox.net/pipermail/buildroot/attachments/20120112/35855967/attachment-0001.html
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120117/564eb079/attachment.html>
^ permalink raw reply
* Re: Leak in rdma_get_cm_event on pthread_cancel?
From: Flavio Baronti @ 2012-01-17 8:52 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120116223541.GA2892-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Il 1/16/2012 23:35 PM, Jason Gunthorpe ha scritto:
> On Tue, Jan 17, 2012 at 12:15:23AM +0200, Or Gerlitz wrote:
>> Flavio Baronti<f.baronti-ngIpsMLAhaq41k5uCYKmRQ@public.gmane.org> wrote:
>>> what is then the proper way to stop a thread blocked on
>>> rdma_get_cm_event() (or on ibv_get_cq_event())?
>>
>> Oh, this is simple - don't get there... have your code
>>
>> 1. get the FDs associated with IB - which you can retrieve from
>> librdmacm and from libibverbs
>>
>> 2. make them non blocking
>>
>> 3. add them to you select/poll FD group
>
> 4. Use an eventfd or otherwise to break out of the select/poll loop
> and then exit your thread.
>
> Jason
Thanks, I did not think about eventfd+select.
Flavio
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 7/8] dmaengine/dw_dmac: Unmap all memory buffers after completion of slave transfers
From: Linus Walleij @ 2012-01-17 8:52 UTC (permalink / raw)
To: Viresh Kumar
Cc: Russell King - ARM Linux, vinod.koul@intel.com,
dan.j.williams@intel.com, Pratyush ANAND, Rajeev KUMAR,
Bhupesh SHARMA, Armando VISCONTI, Mirko GARDI,
linux-kernel@vger.kernel.org, Vipin KUMAR, Shiraz HASHIM,
Amit VIRDI, Vipul Kumar SAMAR, viresh.linux@gmail.com,
Deepak SIKRI, Bhavna YADAV, linux-arm-kernel@lists.infradead.org,
Vincenzo FRASCINO
In-Reply-To: <4F140DB7.3060300@st.com>
On Mon, Jan 16, 2012 at 12:44 PM, Viresh Kumar <viresh.kumar@st.com> wrote:
> On 1/16/2012 4:24 PM, Russell King - ARM Linux wrote:
>> Note that DMA engine drivers are not responsible for unmapping the buffers
>> when the transfer completes - that is the responsibility of the caller.
>>
>> The automatic buffer unmapping is required for the async_tx APIs and
>> offload APIs.
>
> In dw_dmac, it is only done for slave transfers. Is this Okay ??
Basically the driver using the dmaengine shall map/unmap buffers
used for slave transfers, not the driver.
I usually map them before setting up a transfer and unmaps them
when egtting the callback from the DMA engine that the transfer is
complete.
Why do you want to do this?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 7/8] dmaengine/dw_dmac: Unmap all memory buffers after completion of slave transfers
From: Linus Walleij @ 2012-01-17 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F140DB7.3060300@st.com>
On Mon, Jan 16, 2012 at 12:44 PM, Viresh Kumar <viresh.kumar@st.com> wrote:
> On 1/16/2012 4:24 PM, Russell King - ARM Linux wrote:
>> Note that DMA engine drivers are not responsible for unmapping the buffers
>> when the transfer completes - that is the responsibility of the caller.
>>
>> The automatic buffer unmapping is required for the async_tx APIs and
>> offload APIs.
>
> In dw_dmac, it is only done for slave transfers. Is this Okay ??
Basically the driver using the dmaengine shall map/unmap buffers
used for slave transfers, not the driver.
I usually map them before setting up a transfer and unmaps them
when egtting the callback from the DMA engine that the transfer is
complete.
Why do you want to do this?
Yours,
Linus Walleij
^ permalink raw reply
* [U-Boot] [PATCH 3/3] WIP: tegra: i2c: Enable new I2C framework
From: Heiko Schocher @ 2012-01-17 8:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1326784345-19953-4-git-send-email-sjg@chromium.org>
Hello Simon,
Simon Glass wrote:
> This is just a rough patch to show how this might be done.
>
> Not to be applied, please.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
> drivers/i2c/tegra2_i2c.c | 53 +++++++++++++++++++------------------------
> include/configs/seaboard.h | 2 +
> 2 files changed, 25 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/i2c/tegra2_i2c.c b/drivers/i2c/tegra2_i2c.c
> index b42d9ac..93f3269 100644
> --- a/drivers/i2c/tegra2_i2c.c
> +++ b/drivers/i2c/tegra2_i2c.c
> @@ -30,7 +30,9 @@
> #include <asm/arch/gpio.h>
> #include <asm/arch/pinmux.h>
> #include <asm/arch/tegra2_i2c.h>
> +
> #include <fdtdec.h>
> +#include <i2c.h>
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -296,12 +298,7 @@ static int tegra2_i2c_read_data(u32 addr, u8 *data, u32 len)
> #error "Please enable device tree support to use this driver"
> #endif
>
> -unsigned int i2c_get_bus_speed(void)
> -{
> - return i2c_controllers[i2c_bus_num].speed;
> -}
> -
> -int i2c_set_bus_speed(unsigned int speed)
> +uint tegra_i2c_set_bus_speed(unsigned int speed)
static
> {
> struct i2c_bus *i2c_bus;
>
> @@ -309,7 +306,7 @@ int i2c_set_bus_speed(unsigned int speed)
> i2c_bus->speed = speed;
> i2c_init_controller(i2c_bus);
>
> - return 0;
> + return 0; /* TODO: return actual speed */
> }
>
> static int i2c_get_config(const void *blob, int node, struct i2c_bus *i2c_bus)
> @@ -404,7 +401,7 @@ int i2c_init_board(void)
> return 0;
> }
>
> -void i2c_init(int speed, int slaveaddr)
> +void tegra_i2c_init(int speed, int slaveaddr)
static, add this for all functions
[...]
> diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h
> index d2d0115..64c804a 100644
> --- a/include/configs/seaboard.h
> +++ b/include/configs/seaboard.h
> @@ -79,6 +79,8 @@
> #define CONFIG_SYS_MAX_I2C_BUS 4
This define is no longer valid if using the new framework.
Do you have really 4 busses with only one i2c adapter?
This works only, if you have i2c muxes! In this case you have to
define
/*
* how many muxes are maximal consecutively connected on
* one i2c bus
*/
#define CONFIG_SYS_I2C_MAX_HOPS 1
and for example using a PCA9547 mux:
#define CONFIG_SYS_I2C_BUSSES { {0, {I2C_NULL_HOP}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 1}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 2}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 3}}},
}
or you use other i2c adapters like soft_i2c, but I could not see
this in your patch ... and in this case you must define
CONFIG_SYS_NUM_I2C_ADAPTERS ...
> #define CONFIG_SYS_I2C_SPEED 100000
should not longer be defined, instead you should make a option to define
a i2c speed for your i2c driver ... for example
#define CONFIG_SYS_I2C_TEGRA2_SPEED 100000
> #define CONFIG_CMD_I2C
> +#define CONFIG_SYS_I2C
> +#define CONFIG_SYS_I2C_ADAPTERS {&tegra_i2c_adap}
You must have a define in drivers/i2c/Makefile which "activates" your
drivers/i2c/tegra2_i2c.c ... this must defined in your board config
file too (maybe a CONFIG_SYS_I2C_TEGRA2 ?)!
Also you must have a change in drivers/i2c/i2c_core.c
#ifdef CONFIG_SYS_I2C_TEGRA2
extern struct i2c_adap tegra_i2c_adap[];
#endif
or?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [linux-lvm] lvcreate fails
From: Marcus Haarmann @ 2012-01-17 8:50 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <4F0C6912.6040606@canonical.com>
Hi,
thanks for the input, found the (same) resolution after hours of reading
and trying...
(I am newly subscribed to the list, so the response reached me on the
following day).
But yes, the link is maintained by udev.
I have no idea why especially this device was in a mode that allocation
was prevented. We surely did not issue a
pvchange command to do this. (other devices also maintained by lvm, in
the same SAN, were allocatable.
Maybe it is because the array is visible to more than one machine at the
same time due to the fibre switch.
We can address the LVM from more than one machine, which is by intention
to be able to fail over.
Thank you for your ideas.
Best regards,
Marcus
-----Original Message-----
From: Peter M. Petrakis [mailto:peter.petrakis@canonical.com]
Sent: Tuesday, January 10, 2012 5:37 PM
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] lvcreate fails
Hi,
On 01/09/2012 04:08 PM, Marcus Haarmann wrote:
> Hi experts,
>
> I have configured an external disk array on Ubuntu (amd64, 2.6.32
> kernel) with lvm2 (2.02.54) The setup is as follows:
>
> --- Physical volume ---
> PV Name /dev/fc_keep1a_1 (this is a symbolic link to a
fibre channel device)
> VG Name vg_uni
> PV Size 555,23 GiB / not usable 2,20 MiB
> Allocatable NO
> PE Size 4,00 MiB
> Total PE 142139
> Free PE 65339
> Allocated PE 76800
> PV UUID SmOTSP-wPEd-ZruJ-XP8n-WpoL-anDN-ccG7dM
>
> vgdisplay vg_uni
> --- Volume group ---
> VG Name vg_uni
> System ID
> Format lvm2
> Metadata Areas 1
> Metadata Sequence No 20
> VG Access read/write
> VG Status resizable
> MAX LV 0
> Cur LV 4
> Open LV 0
> Max PV 0
> Cur PV 1
> Act PV 1
> VG Size 555,23 GiB
> PE Size 4,00 MiB
> Total PE 142139
> Alloc PE / Size 76800 / 300,00 GiB
> Free PE / Size 65339 / 255,23 GiB
> VG UUID 0VNl5W-W22T-HEow-LvNx-gopm-nS0z-FpjZvi
> This is for a database working with raw devices (without filesystem),
I allocated multiple partitions:
> 100 GB root
> 50 GB blob1
> 50 GB blob2
> 100 GB data1
>
> When I try to allocate another area with 10 GB for a temporary space,
I get an error:
> lvcreate -L 10G -n dbs_uni_tmp vg_uni
> Insufficient free space: 2560 extents needed, but only 0 available
>
> I did -vvv so the layout is printed (note there have been other lvm
partitions which have been dropped):
> Using cached label for /dev/fc_keep1a_1
> Using cached label for /dev/fc_keep1a_1
> Read vg_unister metadata (20) from /dev/fc_keep1a_1 at 47104
size 1723
> /dev/fc_keep1a_1 0: 0 25600: dbs_uni_root(0:0)
> /dev/fc_keep1a_1 1: 25600 25600: dbs_uni_data1(0:0)
> /dev/fc_keep1a_1 2: 51200 64000: NULL(0:0)
> /dev/fc_keep1a_1 3: 115200 12800: dbs_uni_blob1(0:0)
> /dev/fc_keep1a_1 4: 128000 12800: dbs_uni_blob2(0:0)
> /dev/fc_keep1a_1 5: 140800 1339: NULL(0:0)
> Archiving volume group "vg_unister" metadata (seqno 20).
> Creating logical volume dbs_unister_tmp
> Insufficient free space: 1338 extents needed, but only 0 available
> Unlocking /var/lock/lvm/V_vg_unister
> _undo_flock /var/lock/lvm/V_vg_unister
> Closed /dev/fc_keep1a_1
> What can I do to be able to use the space ?
Did you notice that the backing store was state where Allocatable is NO?
Try, # pvchange -x y /dev/fc_keep1a_1
I question the use of that symlink, is it being maintained by UDEV or
multipath friendly names? Could you please elaborate more concerning the
events leading to this point? It doesn't make much sense that LVM would
flip the Allocatable bit without some good external reason. Thanks.
Peter
> Thank you all for your thoughts !
>
> Marcus Haarmann
>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
^ permalink raw reply
* Re: [dm-crypt] cryptsetup luksClose
From: Milan Broz @ 2012-01-17 8:50 UTC (permalink / raw)
To: Marc Schwarzschild; +Cc: dm-crypt
In-Reply-To: <20244.14509.740805.435411@ny.koplon.com>
On 01/16/2012 03:48 PM, Marc Schwarzschild wrote:
> I am setting up an external USB encrypted drive. I can mount it
> manually after I boot the computer. I understand that I must
> issue the 'cryptsetup luksClose' after I umount the disk. How do
> I arrange for this as part of the Debian halt process so it
> happens automatically when the server is shutdown?
It is not cryptsetup job, it should be part of initscripts/systemd
to correctly unmap active devices on shutdown.
(Usually it tries to unmap all crypto disks except device
with root fs which is just remounted read-only. Recent systemd is able
to unmouteven root device properly.)
For hot-plugged disks it is usually handled by some GUI service,
usually based on udisks.
> What happens
> if there is a power failure and 'cryptsetup luksClose' was not
> executed?
For LUKS, no need to worry after power failure - luksClose
just remove kernel mapping (kernel state) it doesn't touch
on-disk metadata at all.
(Of course there can be some filesystem damage after power failure,
but that's not LUKS related, it can happen even for unencrypted fs.)
Milan
^ permalink raw reply
* [PATCH] sh: fix the sh_mmcif_plat_data in board-sh7757lcr
From: Shimoda, Yoshihiro @ 2012-01-17 8:49 UTC (permalink / raw)
To: linux-sh
The board has an eMMC chip, so we cannot remove the chip.
In this case, we have to set the MMC_CAP_NONREMOVABLE to the caps
parameter.
Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
arch/sh/boards/board-sh7757lcr.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/sh/boards/board-sh7757lcr.c b/arch/sh/boards/board-sh7757lcr.c
index 0838154..33dc5b6 100644
--- a/arch/sh/boards/board-sh7757lcr.c
+++ b/arch/sh/boards/board-sh7757lcr.c
@@ -222,7 +222,8 @@ static struct sh_mmcif_dma sh7757lcr_mmcif_dma = {
static struct sh_mmcif_plat_data sh_mmcif_plat = {
.dma = &sh7757lcr_mmcif_dma,
.sup_pclk = 0x0f,
- .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA |
+ MMC_CAP_NONREMOVABLE,
.ocr = MMC_VDD_32_33 | MMC_VDD_33_34,
};
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 8/8] dmaengine/dw_dmac: Add support for DMA_SLAVE_CONFIG
From: Linus Walleij @ 2012-01-17 8:49 UTC (permalink / raw)
To: Viresh Kumar
Cc: vinod.koul@intel.com, dan.j.williams@intel.com,
linux@arm.linux.org.uk, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Armando VISCONTI,
Shiraz HASHIM, Vipin KUMAR, Rajeev KUMAR, Deepak SIKRI,
Vipul Kumar SAMAR, Amit VIRDI, Pratyush ANAND, Bhupesh SHARMA,
viresh.linux@gmail.com, Bhavna YADAV, Vincenzo FRASCINO,
Mirko GARDI
In-Reply-To: <4F140D25.1000309@st.com>
On Mon, Jan 16, 2012 at 12:42 PM, Viresh Kumar <viresh.kumar@st.com> wrote:
> On 1/16/2012 3:20 PM, Viresh KUMAR wrote:
>> + /*
>> + * Fix sconfig's burst size according to dw_dmac. We need to convert
>> + * them as: 1 -> 0, 2 -> 1, 4 -> 2, 8 -> 3, 16 -> 4.
>> + *
>> + * This can be done by findiding least significant bit set: n & (n - 1)
>> + */
>> + sconfig->src_maxburst &= sconfig->src_maxburst - 1;
>> + sconfig->dst_maxburst &= sconfig->dst_maxburst - 1;
>
> Perhaps, this looks incorrect. It will always return 0. :(
> Can somebody suggest any inbuild function to do this, i think
>
> find_next_bit(sconfig->src_maxburst, sizeof(sconfig->src_maxburst), 0)
>
> will do it.
Are you looking for ffs() from <linus/bitops.h>?
find-first-set (the include boils down to include/asm-generic/bitops/ffs.h
if you want to check the implementation).
Linus Walleij
^ permalink raw reply
* [PATCH 8/8] dmaengine/dw_dmac: Add support for DMA_SLAVE_CONFIG
From: Linus Walleij @ 2012-01-17 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F140D25.1000309@st.com>
On Mon, Jan 16, 2012 at 12:42 PM, Viresh Kumar <viresh.kumar@st.com> wrote:
> On 1/16/2012 3:20 PM, Viresh KUMAR wrote:
>> + ? ? /*
>> + ? ? ?* Fix sconfig's burst size according to dw_dmac. We need to convert
>> + ? ? ?* them as: 1 -> 0, 2 -> 1, 4 -> 2, 8 -> 3, 16 -> 4.
>> + ? ? ?*
>> + ? ? ?* This can be done by findiding least significant bit set: n & (n - 1)
>> + ? ? ?*/
>> + ? ? sconfig->src_maxburst &= sconfig->src_maxburst - 1;
>> + ? ? sconfig->dst_maxburst &= sconfig->dst_maxburst - 1;
>
> Perhaps, this looks incorrect. It will always return 0. :(
> Can somebody suggest any inbuild function to do this, i think
>
> find_next_bit(sconfig->src_maxburst, sizeof(sconfig->src_maxburst), 0)
>
> will do it.
Are you looking for ffs() from <linus/bitops.h>?
find-first-set (the include boils down to include/asm-generic/bitops/ffs.h
if you want to check the implementation).
Linus Walleij
^ permalink raw reply
* Re: Updated btrfs/crypto snappy interface ready for merging
From: Andi Kleen @ 2012-01-17 8:46 UTC (permalink / raw)
To: Li Zefan; +Cc: Chris Mason, Andi Kleen, linux-kernel, linux-btrfs
In-Reply-To: <4F1534FD.30707@cn.fujitsu.com>
> It's because decompressing inline extents always fails. I've fixed it
> and will send the patch out in a new mail thread.
Thanks for fixing.
>
> But seems there's bug in lib snappy code, which makes the decompressed
> data doesn't quite match the original data.
>
> Simply copy a file to a btrfs filesystem with snappy enabled, and clear
> page cache, and check the file:
Hmm weird, I have never seen this. Do you have a reproducer?
The basic compression code is quite well tested, I have a reasonable
unit test.
-Andi
^ permalink raw reply
* RE: [PATCH] pinctrl: pin configuration states
From: Dong Aisheng-B29396 @ 2012-01-17 8:46 UTC (permalink / raw)
To: Linus Walleij, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Stephen Warren, Grant Likely, Barry Song, Guo Shawn-R65073,
Thomas Abraham, Dong Aisheng, Rajendra Nayak, Haojian Zhuang,
Linus Walleij
In-Reply-To: <1326725496-28928-1-git-send-email-linus.walleij@stericsson.com>
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Linus Walleij
> Sent: Monday, January 16, 2012 10:52 PM
> To: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> Cc: Stephen Warren; Grant Likely; Barry Song; Guo Shawn-R65073; Thomas Abraham;
> Dong Aisheng; Rajendra Nayak; Haojian Zhuang; Linus Walleij
> Subject: [PATCH] pinctrl: pin configuration states
>
> From: Linus Walleij <linus.walleij@linaro.org>
>
> This introduce a pin configuration state structure and activation functions
> similar to the pinmux map. It basically names a few states and define the custom
> configuration values to be applied to groups and pins alike when switching to a
> certain state.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Maybe this is closer to what people want for configuring the pins in their
> platforms?
Yes, this patch provides a way to us to do platform specific pinconfig initialization,
And different pinctrl states also supported.
> I am not fully satisfied with this solution because it basically
> maintains status quo of the big static tables found in many ARM SoCs, but it
> does instill a common scheme for doing it.
>
> Also there is no way for a pinmux and its associated device to switch states in
> this solution. However one does not exclude the other, we might want per-device
> associated pinmux and group states *also*.
>
I guess this may be needed for some devices wanting to set different pin configuration
During runtime.
For example, IMX6Q usdhc needs to set different pinconfig when working on different
Clock frequency after detecting different cards.
> Comments welcome.
> ---
> Documentation/pinctrl.txt | 63 +++++++++++
> drivers/pinctrl/core.c | 3 +
> drivers/pinctrl/pinconf.c | 231 +++++++++++++++++++++++++++++++++++++-
> drivers/pinctrl/pinconf.h | 11 ++
> include/linux/pinctrl/machine.h | 79 +++++++++++++
> 5 files changed, 380 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index
> 1851f1d..29845c4 100644
> --- a/Documentation/pinctrl.txt
> +++ b/Documentation/pinctrl.txt
> @@ -277,6 +277,69 @@ case each individual pin will be treated by separate
> pin_config_set() calls as well.
>
>
> +Pin configuration states
> +========================
> +
> +To help platforms to set up initial pin configuration and transit the
> +entire set of pins on a pin controller between different states, pin
> +controller states are supported by creating named states per
> +controller. A board/machine can define a pin configuration like this:
> +
> +static const struct pin_config foo_pin_config_active[] = {
> + PIN_CONFIG("GPIO0", PLATFORM_X_PULL_UP),
> + PIN_CONFIG("GPIO1", PLATFORM_X_PULL_DOWN), };
> +
> +static const struct pin_config foo_pin_config_idle[] = {
> + PIN_CONFIG("GPIO0", PLATFORM_X_GROUND),
> + PIN_CONFIG("GPIO1", PLATFORM_X_GROUND), };
> +
> +static const struct pin_config foo_pin_config_idle[] = {
s/foo_pin_config_idle/foo_pin_config_off
> + PIN_CONFIG("GPIO0", PLATFORM_X_OFF),
> + PIN_CONFIG("GPIO1", PLATFORM_X_OFF),
> +};
> +
> +static struct pin_config_state __initdata foo_pinconf_states[] = {
> + {
> + .name = "active",
> + .ctrl_dev_name = "foo",
> + .pin_configs = foo_pin_config_active,
> + .nr_pin_configs = ARRAY_SIZE(foo_pin_config_active),
> + .apply_on_init = true,
> + },
> + {
> + .name = "idle",
> + .ctrl_dev_name = "foo",
> + .pin_configs = foo_pin_config_idle,
> + .nr_pin_configs = ARRAY_SIZE(foo_pin_config_idle),
> + },
> + {
> + .name = "off",
> + .ctrl_dev_name = "foo",
> + .pin_configs = foo_pin_config_idle,
s/foo_pin_config_idle/foo_pin_config_off
> + .nr_pin_configs = ARRAY_SIZE(foo_pin_config_idle),
> + .apply_on_exit = true,
> + },
> +};
> +
> +The first three arrays of configurations are simply the names of some
> +pins and the custom configuration that is associated with each.
> +
> +So there are three states for the pin controller, and the "active"
> +state will pull two GPIO pins,
This sentence does not align with what you define above.
> whereas "idle" will ground them and
> +"off" will deactivate them completely. In this case "active" will be
> +auto-applied when your pin controller registers, and "off" will be
> +auto-applied when the controller is removed. At runtime, the system may want to
> ground both pins by simply calling:
> +
> +ret = pinconf_set_state("foo", "idle");
> +
Maybe:
s/"foo"/"pinctrl-foo"
Easier to understand.
> +Which will apply the "idle" configuration.
> +
> +For simple systems that just configure the pins on boot and then forget
> +about them, the first configuration table may be sufficient.
> +
> +
> Generic pin configuration
> =========================
>
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c index
> 569bdb3..15d5adf 100644
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -541,6 +541,7 @@ static void pinctrl_init_debugfs(void)
> debugfs_create_file("pinctrl-devices", S_IFREG | S_IRUGO,
> debugfs_root, NULL, &pinctrl_devices_ops);
> pinmux_init_debugfs(debugfs_root);
> + pinconf_init_debugfs(debugfs_root);
> }
>
> #else /* CONFIG_DEBUG_FS */
> @@ -622,6 +623,7 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc
> *pctldesc,
> list_add(&pctldev->node, &pinctrldev_list);
> mutex_unlock(&pinctrldev_list_mutex);
> pinmux_hog_maps(pctldev);
> + pinconf_apply_initexit(pctldev, true);
> return pctldev;
>
> out_err:
> @@ -642,6 +644,7 @@ void pinctrl_unregister(struct pinctrl_dev *pctldev)
> return;
>
> pinmux_unhog_maps(pctldev);
> + pinconf_apply_initexit(pctldev, false);
> /* TODO: check that no pinmuxes are still active? */
> mutex_lock(&pinctrldev_list_mutex);
> list_del(&pctldev->node);
> diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c index
> 819fcd9..5830786 100644
> --- a/drivers/pinctrl/pinconf.c
> +++ b/drivers/pinctrl/pinconf.c
> @@ -23,6 +23,10 @@
> #include "core.h"
> #include "pinconf.h"
>
> +/* Global pin configuration states */
> +static struct pin_config_state *pinconf_states; static unsigned
> +pinconf_states_num;
> +
> int pin_config_get_for_pin(struct pinctrl_dev *pctldev, unsigned pin,
> unsigned long *config)
> {
> @@ -138,11 +142,10 @@ int pin_config_group_get(const char *dev_name, const char
> *pin_group, } EXPORT_SYMBOL(pin_config_group_get);
>
> -
> -int pin_config_group_set(const char *dev_name, const char *pin_group,
> - unsigned long config)
> +static int pin_config_group_set_for_group(struct pinctrl_dev *pctldev,
> + const char *pin_group,
> + unsigned long config)
> {
> - struct pinctrl_dev *pctldev;
> const struct pinconf_ops *ops;
> const struct pinctrl_ops *pctlops;
> int selector;
> @@ -151,9 +154,6 @@ int pin_config_group_set(const char *dev_name, const char
> *pin_group,
> int ret;
> int i;
>
> - pctldev = get_pinctrl_dev_from_dev(NULL, dev_name);
> - if (!pctldev)
> - return -EINVAL;
> ops = pctldev->desc->confops;
> pctlops = pctldev->desc->pctlops;
>
> @@ -203,6 +203,20 @@ int pin_config_group_set(const char *dev_name, const char
> *pin_group,
>
> return 0;
> }
> +
> +int pin_config_group_set(const char *dev_name, const char *pin_group,
> + unsigned long config)
> +{
> + struct pinctrl_dev *pctldev;
> +
> + pctldev = get_pinctrl_dev_from_dev(NULL, dev_name);
> + if (!pctldev)
> + return -EINVAL;
> +
> + return pin_config_group_set_for_group(pctldev,
> + pin_group,
> + config);
> +}
> EXPORT_SYMBOL(pin_config_group_set);
>
> int pinconf_check_ops(const struct pinconf_ops *ops) @@ -216,6 +230,167 @@ int
> pinconf_check_ops(const struct pinconf_ops *ops)
> return 0;
> }
>
> +int __init pinconf_register_pin_states(struct pin_config_state const *states,
> + unsigned num_states)
> +{
> + void *tmp;
> + int i;
> +
> + pr_debug("add %d pin configuration states\n", num_states);
> +
> + /* First sanity check the new states */
> + for (i = 0; i < num_states; i++) {
> + if (!states[i].name) {
> + pr_err("failed to register config state %d: "
> + "no state name given\n", i);
> + return -EINVAL;
> + }
> +
> + if (!states[i].ctrl_dev && !states[i].ctrl_dev_name) {
> + pr_err("failed to register config state %s (%d): "
> + "no pin control device given\n",
> + states[i].name, i);
> + return -EINVAL;
> + }
> +
> + if (!states[i].pin_configs && !states[i].pin_group_configs) {
> + pr_err("failed to register config state %s (%d): "
> + "no pin or group states defined in it\n",
> + states[i].name, i);
> + return -EINVAL;
> + }
> + else
Do we need this 'else'?
> + pr_debug("register pin config state %s\n",
> + states[i].name);
> + }
> +
> + /*
> + * Make a copy of the config state array - string pointers will end up
> + * in the kernel const section anyway so these do not need to be deep
> + * copied. Note that the pointers to the config tuples are *not* being
> + * copied as of now, these cannot be declared __init_data.
> + */
> + if (!pinconf_states_num) {
> + /* On first call, just copy them */
> + tmp = kmemdup(states,
> + sizeof(struct pin_config_state) * num_states,
> + GFP_KERNEL);
> + if (!tmp)
> + return -ENOMEM;
> + } else {
> + /* Subsequent calls, reallocate array to new size */
> + size_t oldsize = sizeof(struct pin_config_state) *
> + pinconf_states_num;
> + size_t newsize = sizeof(struct pin_config_state) * num_states;
> +
> + tmp = krealloc(pinconf_states, oldsize + newsize, GFP_KERNEL);
> + if (!tmp)
> + return -ENOMEM;
> + memcpy((tmp + oldsize), states, newsize);
> + }
> +
> + pinconf_states = tmp;
> + pinconf_states_num += num_states;
> + return 0;
> +}
> +
> +/**
> + * pinconf_apply_state() - apply a certain pin configuration state on a
> +certain
> + * pin controller
> + * @pctldev: the pin controller to apply the state to
> + * @pstate: the configuration state to apply on the pin controller */
> +static int pinconf_apply_state(struct pinctrl_dev *pctldev,
> + struct pin_config_state const *pstate) {
> + int ret, i;
> +
> + /* Apply group configs first */
> + for (i = 0; i < pstate->nr_pin_group_configs; i++) {
> + const struct pin_group_config *groupconf =
> + &pstate->pin_group_configs[i];
> +
> + ret = pin_config_group_set_for_group(pctldev,
> + groupconf->group_name,
> + groupconf->config);
> + if (ret < 0)
> + return ret;
> + }
> +
> + /* Then apply individual pin configs */
> + for (i = 0; i < pstate->nr_pin_configs; i++) {
> + const struct pin_config *pinconf =
> + &pstate->pin_configs[i];
> + int pin;
> +
> + pin = pin_get_from_name(pctldev, pinconf->pin_name);
> + if (pin < 0)
> + return pin;
> +
> + ret = pin_config_set_for_pin(pctldev, pin, pinconf->config);
> + if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * pinconf_set_state() - sets the state for pins and groups on a pin
> +controller
> + * @dev_name: the textual name for the pin controller
> + * @state: name of the state to set
> + */
> +int pinconf_activate_state(const char *dev_name, const char *state) {
s/ pinconf_activate_state/ pinconf_set_state ?
Also, I did not see this function in the .h file.
> + struct pinctrl_dev *pctldev;
> + int i;
> +
> + pctldev = get_pinctrl_dev_from_dev(NULL, dev_name);
> + if (!pctldev)
> + return -EINVAL;
> +
> + for (i = 0; i < pinconf_states_num; i++) {
> + struct pin_config_state const *pstate = &pinconf_states[i];
> + int ret;
> +
> + if (!strcmp(pstate->name, state)) {
> + ret = pinconf_apply_state(pctldev, pstate);
> + if (ret)
> + dev_err(pctldev->dev,
> + "failed to apply state %s\n",
> + pstate->name);
> + }
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * pinconf_apply_initexit() - check for states to be applied on init
> +and exit
> + * @pctldev: pin controller to be checked
> + * @init: true for checking during registration of the pin controller, false
> + * for checking during removal of the pin controller
> + */
> +void pinconf_apply_initexit(struct pinctrl_dev *pctldev, bool init) {
> + int i;
> +
> + for (i = 0; i < pinconf_states_num; i++) {
> + struct pin_config_state const *pstate = &pinconf_states[i];
> + int ret;
> +
> + if ((pstate->apply_on_init && init) ||
> + (pstate->apply_on_exit && !init)) {
> + ret = pinconf_apply_state(pctldev, pstate);
> + if (ret)
> + dev_err(pctldev->dev,
> + "failed to apply state %s on %s\n",
> + pstate->name,
> + init ? "init" : "exit");
> + }
> + }
> +}
> +
> #ifdef CONFIG_DEBUG_FS
>
> static void pinconf_dump_pin(struct pinctrl_dev *pctldev, @@ -294,6 +469,30 @@
> static int pinconf_groups_show(struct seq_file *s, void *what)
> return 0;
> }
>
> +static int pinconf_states_show(struct seq_file *s, void *what) {
> + int i;
> +
> + seq_puts(s, "Pinconfig state table:\n");
> +
> + for (i = 0; i < pinconf_states_num; i++) {
> + struct pin_config_state const *pstate = &pinconf_states[i];
> +
> + seq_printf(s, "%s:\n", pstate->name);
> + seq_printf(s, " controlling device %s\n",
> + pstate->ctrl_dev ? dev_name(pstate->ctrl_dev) :
> + pstate->ctrl_dev_name);
> + seq_printf(s, " %u pin configs, %u pin group configs\n",
> + pstate->nr_pin_configs,
> + pstate->nr_pin_group_configs);
> + seq_printf(s, " apply on init: %s\n",
> + pstate->apply_on_init ? "YES" : "NO");
> + seq_printf(s, " apply on exit: %s\n",
> + pstate->apply_on_exit ? "YES" : "NO");
> + }
> + return 0;
> +}
> +
> static int pinconf_pins_open(struct inode *inode, struct file *file) {
> return single_open(file, pinconf_pins_show, inode->i_private); @@ -304,6
> +503,11 @@ static int pinconf_groups_open(struct inode *inode, struct file *file)
> return single_open(file, pinconf_groups_show, inode->i_private); }
>
> +static int pinconf_states_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, pinconf_states_show, inode->i_private); }
> +
> static const struct file_operations pinconf_pins_ops = {
> .open = pinconf_pins_open,
> .read = seq_read,
> @@ -318,6 +522,13 @@ static const struct file_operations pinconf_groups_ops = {
> .release = single_release,
> };
>
> +static const struct file_operations pinconf_states_ops = {
> + .open = pinconf_states_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> +};
> +
> void pinconf_init_device_debugfs(struct dentry *devroot,
> struct pinctrl_dev *pctldev)
> {
> @@ -327,4 +538,10 @@ void pinconf_init_device_debugfs(struct dentry *devroot,
> devroot, pctldev, &pinconf_groups_ops); }
>
> +void pinconf_init_debugfs(struct dentry *subsys_root) {
> + debugfs_create_file("pinconf-states", S_IFREG | S_IRUGO,
> + subsys_root, NULL, &pinconf_states_ops); }
> +
> #endif
> diff --git a/drivers/pinctrl/pinconf.h b/drivers/pinctrl/pinconf.h index
> 81d71ae..f5872d4 100644
> --- a/drivers/pinctrl/pinconf.h
> +++ b/drivers/pinctrl/pinconf.h
> @@ -14,8 +14,10 @@
> #ifdef CONFIG_PINCONF
>
> int pinconf_check_ops(const struct pinconf_ops *ops);
> +void pinconf_apply_initexit(struct pinctrl_dev *pctldev, bool init);
> void pinconf_init_device_debugfs(struct dentry *devroot,
> struct pinctrl_dev *pctldev);
> +void pinconf_init_debugfs(struct dentry *subsys_root);
> int pin_config_get_for_pin(struct pinctrl_dev *pctldev, unsigned pin,
> unsigned long *config);
> int pin_config_set_for_pin(struct pinctrl_dev *pctldev, unsigned pin, @@ -28,11
> +30,20 @@ static inline int pinconf_check_ops(const struct pinconf_ops *ops)
> return 0;
> }
>
> +static inline void pinconf_apply_initexit(struct pinctrl_dev *pctldev,
> + bool init)
> +{
> +}
> +
> static inline void pinconf_init_device_debugfs(struct dentry *devroot,
> struct pinctrl_dev *pctldev) { }
>
> +static inline void pinconf_init_debugfs(struct dentry *subsys_root) { }
> +
> #endif
>
> /*
> diff --git a/include/linux/pinctrl/machine.h b/include/linux/pinctrl/machine.h
> index d0aecb7..a4f78bd 100644
> --- a/include/linux/pinctrl/machine.h
> +++ b/include/linux/pinctrl/machine.h
> @@ -82,6 +82,67 @@ struct pinmux_map {
> { .name = a, .ctrl_dev_name = b, .function = c, .group = d, \
> .hog_on_boot = true }
>
> +/**
> + * struct pin_config - configuration tuple for a single pin
> + * @pin_name: name of the pin affected by this configuration
> + * @config: configuration of the named pin (custom format) */ struct
> +pin_config {
> + const char *pin_name;
> + u32 config;
> +};
> +
> +/*
> + * Convenience macro to set up a simple config for a named pin */
> +#define PIN_CONFIG(a, b) \
> + { .pin_name = a, .config = b }
> +
> +/**
> + * struct pin_group_config - configuration tuple for a group
> + * @group_name: name of the group affected by this configuration
> + * @config: configuration of the named group (custom format) */ struct
> +pin_group_config {
> + const char *group_name;
> + u32 config;
> +};
> +
> +/*
> + * Convenience macro to set up a simple config for a named pin group
> +*/ #define PIN_GROUP_CONFIG(a, b) \
> + { .group_name = a, .config = b }
> +
> +/**
> + * struct pin_config_state - configuration for an array of pins
> + * @name: name of this configuration state
> + * @ctrl_dev: the pin control device to be used for this state, may be NULL
> + * if you provide .ctrl_dev_name instead (this is more common)
> + * @ctrl_dev_name: the name of the device controlling this specific state,
> + * the name must be the same as in your struct device*, may be NULL if
> + * you provide .ctrl_dev instead
> + * @pin_configs: array of pin configuration tuples
> + * @nr_pin_configs: number of pin_configuration tuples in the array
> + * @pin_group_configs: array of pin group configuration tuples
> + * @nr_pin_group_configs: number of pin_group_configuration tuples in
> +the array
> + * @apply_on_init: whether this configuration shall be auto-applied when
> + * the pin controller is registered
> + * @apply_on_exit: whether this configuration shall be auto-applied when
> + * the pin controller is unregistered
> + */
> +struct pin_config_state {
> + const char *name;
> + struct device *ctrl_dev;
> + const char *ctrl_dev_name;
> + const struct pin_config *pin_configs;
> + unsigned nr_pin_configs;
> + const struct pin_group_config *pin_group_configs;
> + unsigned nr_pin_group_configs;
> + bool apply_on_init;
> + bool apply_on_exit;
> +};
> +
> #ifdef CONFIG_PINMUX
>
> extern int pinmux_register_mappings(struct pinmux_map const *map, @@ -96,4
> +157,22 @@ static inline int pinmux_register_mappings(struct pinmux_map const
> *map, }
>
> #endif /* !CONFIG_PINMUX */
> +
> +#ifdef CONFIG_PINCONF
> +
> +extern int pinconf_register_pin_states(struct pin_config_state const
> + *states,
> + unsigned num_states);
> +
> +#else
> +
> +static inline int pinconf_register_pin_states(struct pin_config_state const
> + *states,
> + unsigned num_states)
> +{
> + return 0;
> +}
> +
> +#endif /* !CONFIG_PINCONF */
> +
> #endif
> --
> 1.7.8
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* 0,70 euros les shortys dentelles liquidation totale stock limite
From: Dessous Chéri via Monplanshopping @ 2012-01-17 8:46 UTC (permalink / raw)
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Soldes Dessous chéri
Des prix jamais vus
0.70 euro les shortys soit moins 80 pourcent
http://trkmps.monplanshopping.com/clickers/trkclic.php?idlink=190&idint=JXBUC&idcamp=186
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
^ permalink raw reply
* [PATCH] pinctrl: pin configuration states
From: Dong Aisheng-B29396 @ 2012-01-17 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1326725496-28928-1-git-send-email-linus.walleij@stericsson.com>
> -----Original Message-----
> From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> owner at vger.kernel.org] On Behalf Of Linus Walleij
> Sent: Monday, January 16, 2012 10:52 PM
> To: linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Cc: Stephen Warren; Grant Likely; Barry Song; Guo Shawn-R65073; Thomas Abraham;
> Dong Aisheng; Rajendra Nayak; Haojian Zhuang; Linus Walleij
> Subject: [PATCH] pinctrl: pin configuration states
>
> From: Linus Walleij <linus.walleij@linaro.org>
>
> This introduce a pin configuration state structure and activation functions
> similar to the pinmux map. It basically names a few states and define the custom
> configuration values to be applied to groups and pins alike when switching to a
> certain state.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Maybe this is closer to what people want for configuring the pins in their
> platforms?
Yes, this patch provides a way to us to do platform specific pinconfig initialization,
And different pinctrl states also supported.
> I am not fully satisfied with this solution because it basically
> maintains status quo of the big static tables found in many ARM SoCs, but it
> does instill a common scheme for doing it.
>
> Also there is no way for a pinmux and its associated device to switch states in
> this solution. However one does not exclude the other, we might want per-device
> associated pinmux and group states *also*.
>
I guess this may be needed for some devices wanting to set different pin configuration
During runtime.
For example, IMX6Q usdhc needs to set different pinconfig when working on different
Clock frequency after detecting different cards.
> Comments welcome.
> ---
> Documentation/pinctrl.txt | 63 +++++++++++
> drivers/pinctrl/core.c | 3 +
> drivers/pinctrl/pinconf.c | 231 +++++++++++++++++++++++++++++++++++++-
> drivers/pinctrl/pinconf.h | 11 ++
> include/linux/pinctrl/machine.h | 79 +++++++++++++
> 5 files changed, 380 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index
> 1851f1d..29845c4 100644
> --- a/Documentation/pinctrl.txt
> +++ b/Documentation/pinctrl.txt
> @@ -277,6 +277,69 @@ case each individual pin will be treated by separate
> pin_config_set() calls as well.
>
>
> +Pin configuration states
> +========================
> +
> +To help platforms to set up initial pin configuration and transit the
> +entire set of pins on a pin controller between different states, pin
> +controller states are supported by creating named states per
> +controller. A board/machine can define a pin configuration like this:
> +
> +static const struct pin_config foo_pin_config_active[] = {
> + PIN_CONFIG("GPIO0", PLATFORM_X_PULL_UP),
> + PIN_CONFIG("GPIO1", PLATFORM_X_PULL_DOWN), };
> +
> +static const struct pin_config foo_pin_config_idle[] = {
> + PIN_CONFIG("GPIO0", PLATFORM_X_GROUND),
> + PIN_CONFIG("GPIO1", PLATFORM_X_GROUND), };
> +
> +static const struct pin_config foo_pin_config_idle[] = {
s/foo_pin_config_idle/foo_pin_config_off
> + PIN_CONFIG("GPIO0", PLATFORM_X_OFF),
> + PIN_CONFIG("GPIO1", PLATFORM_X_OFF),
> +};
> +
> +static struct pin_config_state __initdata foo_pinconf_states[] = {
> + {
> + .name = "active",
> + .ctrl_dev_name = "foo",
> + .pin_configs = foo_pin_config_active,
> + .nr_pin_configs = ARRAY_SIZE(foo_pin_config_active),
> + .apply_on_init = true,
> + },
> + {
> + .name = "idle",
> + .ctrl_dev_name = "foo",
> + .pin_configs = foo_pin_config_idle,
> + .nr_pin_configs = ARRAY_SIZE(foo_pin_config_idle),
> + },
> + {
> + .name = "off",
> + .ctrl_dev_name = "foo",
> + .pin_configs = foo_pin_config_idle,
s/foo_pin_config_idle/foo_pin_config_off
> + .nr_pin_configs = ARRAY_SIZE(foo_pin_config_idle),
> + .apply_on_exit = true,
> + },
> +};
> +
> +The first three arrays of configurations are simply the names of some
> +pins and the custom configuration that is associated with each.
> +
> +So there are three states for the pin controller, and the "active"
> +state will pull two GPIO pins,
This sentence does not align with what you define above.
> whereas "idle" will ground them and
> +"off" will deactivate them completely. In this case "active" will be
> +auto-applied when your pin controller registers, and "off" will be
> +auto-applied when the controller is removed. At runtime, the system may want to
> ground both pins by simply calling:
> +
> +ret = pinconf_set_state("foo", "idle");
> +
Maybe:
s/"foo"/"pinctrl-foo"
Easier to understand.
> +Which will apply the "idle" configuration.
> +
> +For simple systems that just configure the pins on boot and then forget
> +about them, the first configuration table may be sufficient.
> +
> +
> Generic pin configuration
> =========================
>
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c index
> 569bdb3..15d5adf 100644
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -541,6 +541,7 @@ static void pinctrl_init_debugfs(void)
> debugfs_create_file("pinctrl-devices", S_IFREG | S_IRUGO,
> debugfs_root, NULL, &pinctrl_devices_ops);
> pinmux_init_debugfs(debugfs_root);
> + pinconf_init_debugfs(debugfs_root);
> }
>
> #else /* CONFIG_DEBUG_FS */
> @@ -622,6 +623,7 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc
> *pctldesc,
> list_add(&pctldev->node, &pinctrldev_list);
> mutex_unlock(&pinctrldev_list_mutex);
> pinmux_hog_maps(pctldev);
> + pinconf_apply_initexit(pctldev, true);
> return pctldev;
>
> out_err:
> @@ -642,6 +644,7 @@ void pinctrl_unregister(struct pinctrl_dev *pctldev)
> return;
>
> pinmux_unhog_maps(pctldev);
> + pinconf_apply_initexit(pctldev, false);
> /* TODO: check that no pinmuxes are still active? */
> mutex_lock(&pinctrldev_list_mutex);
> list_del(&pctldev->node);
> diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c index
> 819fcd9..5830786 100644
> --- a/drivers/pinctrl/pinconf.c
> +++ b/drivers/pinctrl/pinconf.c
> @@ -23,6 +23,10 @@
> #include "core.h"
> #include "pinconf.h"
>
> +/* Global pin configuration states */
> +static struct pin_config_state *pinconf_states; static unsigned
> +pinconf_states_num;
> +
> int pin_config_get_for_pin(struct pinctrl_dev *pctldev, unsigned pin,
> unsigned long *config)
> {
> @@ -138,11 +142,10 @@ int pin_config_group_get(const char *dev_name, const char
> *pin_group, } EXPORT_SYMBOL(pin_config_group_get);
>
> -
> -int pin_config_group_set(const char *dev_name, const char *pin_group,
> - unsigned long config)
> +static int pin_config_group_set_for_group(struct pinctrl_dev *pctldev,
> + const char *pin_group,
> + unsigned long config)
> {
> - struct pinctrl_dev *pctldev;
> const struct pinconf_ops *ops;
> const struct pinctrl_ops *pctlops;
> int selector;
> @@ -151,9 +154,6 @@ int pin_config_group_set(const char *dev_name, const char
> *pin_group,
> int ret;
> int i;
>
> - pctldev = get_pinctrl_dev_from_dev(NULL, dev_name);
> - if (!pctldev)
> - return -EINVAL;
> ops = pctldev->desc->confops;
> pctlops = pctldev->desc->pctlops;
>
> @@ -203,6 +203,20 @@ int pin_config_group_set(const char *dev_name, const char
> *pin_group,
>
> return 0;
> }
> +
> +int pin_config_group_set(const char *dev_name, const char *pin_group,
> + unsigned long config)
> +{
> + struct pinctrl_dev *pctldev;
> +
> + pctldev = get_pinctrl_dev_from_dev(NULL, dev_name);
> + if (!pctldev)
> + return -EINVAL;
> +
> + return pin_config_group_set_for_group(pctldev,
> + pin_group,
> + config);
> +}
> EXPORT_SYMBOL(pin_config_group_set);
>
> int pinconf_check_ops(const struct pinconf_ops *ops) @@ -216,6 +230,167 @@ int
> pinconf_check_ops(const struct pinconf_ops *ops)
> return 0;
> }
>
> +int __init pinconf_register_pin_states(struct pin_config_state const *states,
> + unsigned num_states)
> +{
> + void *tmp;
> + int i;
> +
> + pr_debug("add %d pin configuration states\n", num_states);
> +
> + /* First sanity check the new states */
> + for (i = 0; i < num_states; i++) {
> + if (!states[i].name) {
> + pr_err("failed to register config state %d: "
> + "no state name given\n", i);
> + return -EINVAL;
> + }
> +
> + if (!states[i].ctrl_dev && !states[i].ctrl_dev_name) {
> + pr_err("failed to register config state %s (%d): "
> + "no pin control device given\n",
> + states[i].name, i);
> + return -EINVAL;
> + }
> +
> + if (!states[i].pin_configs && !states[i].pin_group_configs) {
> + pr_err("failed to register config state %s (%d): "
> + "no pin or group states defined in it\n",
> + states[i].name, i);
> + return -EINVAL;
> + }
> + else
Do we need this 'else'?
> + pr_debug("register pin config state %s\n",
> + states[i].name);
> + }
> +
> + /*
> + * Make a copy of the config state array - string pointers will end up
> + * in the kernel const section anyway so these do not need to be deep
> + * copied. Note that the pointers to the config tuples are *not* being
> + * copied as of now, these cannot be declared __init_data.
> + */
> + if (!pinconf_states_num) {
> + /* On first call, just copy them */
> + tmp = kmemdup(states,
> + sizeof(struct pin_config_state) * num_states,
> + GFP_KERNEL);
> + if (!tmp)
> + return -ENOMEM;
> + } else {
> + /* Subsequent calls, reallocate array to new size */
> + size_t oldsize = sizeof(struct pin_config_state) *
> + pinconf_states_num;
> + size_t newsize = sizeof(struct pin_config_state) * num_states;
> +
> + tmp = krealloc(pinconf_states, oldsize + newsize, GFP_KERNEL);
> + if (!tmp)
> + return -ENOMEM;
> + memcpy((tmp + oldsize), states, newsize);
> + }
> +
> + pinconf_states = tmp;
> + pinconf_states_num += num_states;
> + return 0;
> +}
> +
> +/**
> + * pinconf_apply_state() - apply a certain pin configuration state on a
> +certain
> + * pin controller
> + * @pctldev: the pin controller to apply the state to
> + * @pstate: the configuration state to apply on the pin controller */
> +static int pinconf_apply_state(struct pinctrl_dev *pctldev,
> + struct pin_config_state const *pstate) {
> + int ret, i;
> +
> + /* Apply group configs first */
> + for (i = 0; i < pstate->nr_pin_group_configs; i++) {
> + const struct pin_group_config *groupconf =
> + &pstate->pin_group_configs[i];
> +
> + ret = pin_config_group_set_for_group(pctldev,
> + groupconf->group_name,
> + groupconf->config);
> + if (ret < 0)
> + return ret;
> + }
> +
> + /* Then apply individual pin configs */
> + for (i = 0; i < pstate->nr_pin_configs; i++) {
> + const struct pin_config *pinconf =
> + &pstate->pin_configs[i];
> + int pin;
> +
> + pin = pin_get_from_name(pctldev, pinconf->pin_name);
> + if (pin < 0)
> + return pin;
> +
> + ret = pin_config_set_for_pin(pctldev, pin, pinconf->config);
> + if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * pinconf_set_state() - sets the state for pins and groups on a pin
> +controller
> + * @dev_name: the textual name for the pin controller
> + * @state: name of the state to set
> + */
> +int pinconf_activate_state(const char *dev_name, const char *state) {
s/ pinconf_activate_state/ pinconf_set_state ?
Also, I did not see this function in the .h file.
> + struct pinctrl_dev *pctldev;
> + int i;
> +
> + pctldev = get_pinctrl_dev_from_dev(NULL, dev_name);
> + if (!pctldev)
> + return -EINVAL;
> +
> + for (i = 0; i < pinconf_states_num; i++) {
> + struct pin_config_state const *pstate = &pinconf_states[i];
> + int ret;
> +
> + if (!strcmp(pstate->name, state)) {
> + ret = pinconf_apply_state(pctldev, pstate);
> + if (ret)
> + dev_err(pctldev->dev,
> + "failed to apply state %s\n",
> + pstate->name);
> + }
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * pinconf_apply_initexit() - check for states to be applied on init
> +and exit
> + * @pctldev: pin controller to be checked
> + * @init: true for checking during registration of the pin controller, false
> + * for checking during removal of the pin controller
> + */
> +void pinconf_apply_initexit(struct pinctrl_dev *pctldev, bool init) {
> + int i;
> +
> + for (i = 0; i < pinconf_states_num; i++) {
> + struct pin_config_state const *pstate = &pinconf_states[i];
> + int ret;
> +
> + if ((pstate->apply_on_init && init) ||
> + (pstate->apply_on_exit && !init)) {
> + ret = pinconf_apply_state(pctldev, pstate);
> + if (ret)
> + dev_err(pctldev->dev,
> + "failed to apply state %s on %s\n",
> + pstate->name,
> + init ? "init" : "exit");
> + }
> + }
> +}
> +
> #ifdef CONFIG_DEBUG_FS
>
> static void pinconf_dump_pin(struct pinctrl_dev *pctldev, @@ -294,6 +469,30 @@
> static int pinconf_groups_show(struct seq_file *s, void *what)
> return 0;
> }
>
> +static int pinconf_states_show(struct seq_file *s, void *what) {
> + int i;
> +
> + seq_puts(s, "Pinconfig state table:\n");
> +
> + for (i = 0; i < pinconf_states_num; i++) {
> + struct pin_config_state const *pstate = &pinconf_states[i];
> +
> + seq_printf(s, "%s:\n", pstate->name);
> + seq_printf(s, " controlling device %s\n",
> + pstate->ctrl_dev ? dev_name(pstate->ctrl_dev) :
> + pstate->ctrl_dev_name);
> + seq_printf(s, " %u pin configs, %u pin group configs\n",
> + pstate->nr_pin_configs,
> + pstate->nr_pin_group_configs);
> + seq_printf(s, " apply on init: %s\n",
> + pstate->apply_on_init ? "YES" : "NO");
> + seq_printf(s, " apply on exit: %s\n",
> + pstate->apply_on_exit ? "YES" : "NO");
> + }
> + return 0;
> +}
> +
> static int pinconf_pins_open(struct inode *inode, struct file *file) {
> return single_open(file, pinconf_pins_show, inode->i_private); @@ -304,6
> +503,11 @@ static int pinconf_groups_open(struct inode *inode, struct file *file)
> return single_open(file, pinconf_groups_show, inode->i_private); }
>
> +static int pinconf_states_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, pinconf_states_show, inode->i_private); }
> +
> static const struct file_operations pinconf_pins_ops = {
> .open = pinconf_pins_open,
> .read = seq_read,
> @@ -318,6 +522,13 @@ static const struct file_operations pinconf_groups_ops = {
> .release = single_release,
> };
>
> +static const struct file_operations pinconf_states_ops = {
> + .open = pinconf_states_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> +};
> +
> void pinconf_init_device_debugfs(struct dentry *devroot,
> struct pinctrl_dev *pctldev)
> {
> @@ -327,4 +538,10 @@ void pinconf_init_device_debugfs(struct dentry *devroot,
> devroot, pctldev, &pinconf_groups_ops); }
>
> +void pinconf_init_debugfs(struct dentry *subsys_root) {
> + debugfs_create_file("pinconf-states", S_IFREG | S_IRUGO,
> + subsys_root, NULL, &pinconf_states_ops); }
> +
> #endif
> diff --git a/drivers/pinctrl/pinconf.h b/drivers/pinctrl/pinconf.h index
> 81d71ae..f5872d4 100644
> --- a/drivers/pinctrl/pinconf.h
> +++ b/drivers/pinctrl/pinconf.h
> @@ -14,8 +14,10 @@
> #ifdef CONFIG_PINCONF
>
> int pinconf_check_ops(const struct pinconf_ops *ops);
> +void pinconf_apply_initexit(struct pinctrl_dev *pctldev, bool init);
> void pinconf_init_device_debugfs(struct dentry *devroot,
> struct pinctrl_dev *pctldev);
> +void pinconf_init_debugfs(struct dentry *subsys_root);
> int pin_config_get_for_pin(struct pinctrl_dev *pctldev, unsigned pin,
> unsigned long *config);
> int pin_config_set_for_pin(struct pinctrl_dev *pctldev, unsigned pin, @@ -28,11
> +30,20 @@ static inline int pinconf_check_ops(const struct pinconf_ops *ops)
> return 0;
> }
>
> +static inline void pinconf_apply_initexit(struct pinctrl_dev *pctldev,
> + bool init)
> +{
> +}
> +
> static inline void pinconf_init_device_debugfs(struct dentry *devroot,
> struct pinctrl_dev *pctldev) { }
>
> +static inline void pinconf_init_debugfs(struct dentry *subsys_root) { }
> +
> #endif
>
> /*
> diff --git a/include/linux/pinctrl/machine.h b/include/linux/pinctrl/machine.h
> index d0aecb7..a4f78bd 100644
> --- a/include/linux/pinctrl/machine.h
> +++ b/include/linux/pinctrl/machine.h
> @@ -82,6 +82,67 @@ struct pinmux_map {
> { .name = a, .ctrl_dev_name = b, .function = c, .group = d, \
> .hog_on_boot = true }
>
> +/**
> + * struct pin_config - configuration tuple for a single pin
> + * @pin_name: name of the pin affected by this configuration
> + * @config: configuration of the named pin (custom format) */ struct
> +pin_config {
> + const char *pin_name;
> + u32 config;
> +};
> +
> +/*
> + * Convenience macro to set up a simple config for a named pin */
> +#define PIN_CONFIG(a, b) \
> + { .pin_name = a, .config = b }
> +
> +/**
> + * struct pin_group_config - configuration tuple for a group
> + * @group_name: name of the group affected by this configuration
> + * @config: configuration of the named group (custom format) */ struct
> +pin_group_config {
> + const char *group_name;
> + u32 config;
> +};
> +
> +/*
> + * Convenience macro to set up a simple config for a named pin group
> +*/ #define PIN_GROUP_CONFIG(a, b) \
> + { .group_name = a, .config = b }
> +
> +/**
> + * struct pin_config_state - configuration for an array of pins
> + * @name: name of this configuration state
> + * @ctrl_dev: the pin control device to be used for this state, may be NULL
> + * if you provide .ctrl_dev_name instead (this is more common)
> + * @ctrl_dev_name: the name of the device controlling this specific state,
> + * the name must be the same as in your struct device*, may be NULL if
> + * you provide .ctrl_dev instead
> + * @pin_configs: array of pin configuration tuples
> + * @nr_pin_configs: number of pin_configuration tuples in the array
> + * @pin_group_configs: array of pin group configuration tuples
> + * @nr_pin_group_configs: number of pin_group_configuration tuples in
> +the array
> + * @apply_on_init: whether this configuration shall be auto-applied when
> + * the pin controller is registered
> + * @apply_on_exit: whether this configuration shall be auto-applied when
> + * the pin controller is unregistered
> + */
> +struct pin_config_state {
> + const char *name;
> + struct device *ctrl_dev;
> + const char *ctrl_dev_name;
> + const struct pin_config *pin_configs;
> + unsigned nr_pin_configs;
> + const struct pin_group_config *pin_group_configs;
> + unsigned nr_pin_group_configs;
> + bool apply_on_init;
> + bool apply_on_exit;
> +};
> +
> #ifdef CONFIG_PINMUX
>
> extern int pinmux_register_mappings(struct pinmux_map const *map, @@ -96,4
> +157,22 @@ static inline int pinmux_register_mappings(struct pinmux_map const
> *map, }
>
> #endif /* !CONFIG_PINMUX */
> +
> +#ifdef CONFIG_PINCONF
> +
> +extern int pinconf_register_pin_states(struct pin_config_state const
> + *states,
> + unsigned num_states);
> +
> +#else
> +
> +static inline int pinconf_register_pin_states(struct pin_config_state const
> + *states,
> + unsigned num_states)
> +{
> + return 0;
> +}
> +
> +#endif /* !CONFIG_PINCONF */
> +
> #endif
> --
> 1.7.8
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the
> body of a message to majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH 2/2] ARM: prima2: convert to common sched_clock() implementation
From: Barry Song @ 2012-01-17 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1326715537-14968-3-git-send-email-marc.zyngier@arm.com>
2012/1/16 Marc Zyngier <marc.zyngier@arm.com>:
> Prima2 has its own sched_clock() implementation, which gets in the
> way of a single zImage. Moving to the common sched_clock framework
> makes the code slightly cleaner (the mapping hack in sched_clock()
> goes away...).
>
> Cc: Barry Song <baohua.song@csr.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Ack. Thanks, Marc.
-barry
> ---
> ?arch/arm/Kconfig ? ? ? ? ? ? | ? ?1 +
> ?arch/arm/mach-prima2/timer.c | ? 21 +++++++--------------
> ?2 files changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index cb75734..a18550e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -388,6 +388,7 @@ config ARCH_PRIMA2
> ? ? ? ?select GENERIC_CLOCKEVENTS
> ? ? ? ?select CLKDEV_LOOKUP
> ? ? ? ?select GENERIC_IRQ_CHIP
> + ? ? ? select HAVE_SCHED_CLOCK
> ? ? ? ?select MIGHT_HAVE_CACHE_L2X0
> ? ? ? ?select USE_OF
> ? ? ? ?select ZONE_DMA
> diff --git a/arch/arm/mach-prima2/timer.c b/arch/arm/mach-prima2/timer.c
> index b7a6091..0d024b1 100644
> --- a/arch/arm/mach-prima2/timer.c
> +++ b/arch/arm/mach-prima2/timer.c
> @@ -18,6 +18,7 @@
> ?#include <linux/of.h>
> ?#include <linux/of_address.h>
> ?#include <mach/map.h>
> +#include <asm/sched_clock.h>
> ?#include <asm/mach/time.h>
>
> ?#define SIRFSOC_TIMER_COUNTER_LO ? ? ? 0x0000
> @@ -165,21 +166,9 @@ static struct irqaction sirfsoc_timer_irq = {
> ?};
>
> ?/* Overwrite weak default sched_clock with more precise one */
> -unsigned long long notrace sched_clock(void)
> +static u32 notrace sirfsoc_read_sched_clock(void)
> ?{
> - ? ? ? static int is_mapped;
> -
> - ? ? ? /*
> - ? ? ? ?* sched_clock is called earlier than .init of sys_timer
> - ? ? ? ?* if we map timer memory in .init of sys_timer, system
> - ? ? ? ?* will panic due to illegal memory access
> - ? ? ? ?*/
> - ? ? ? if (!is_mapped) {
> - ? ? ? ? ? ? ? sirfsoc_of_timer_map();
> - ? ? ? ? ? ? ? is_mapped = 1;
> - ? ? ? }
> -
> - ? ? ? return sirfsoc_timer_read(NULL) * (NSEC_PER_SEC / CLOCK_TICK_RATE);
> + ? ? ? return (u32)(sirfsoc_timer_read(NULL) & 0xffffffff);
> ?}
>
> ?static void __init sirfsoc_clockevent_init(void)
> @@ -210,6 +199,8 @@ static void __init sirfsoc_timer_init(void)
> ? ? ? ?BUG_ON(rate < CLOCK_TICK_RATE);
> ? ? ? ?BUG_ON(rate % CLOCK_TICK_RATE);
>
> + ? ? ? sirfsoc_of_timer_map();
> +
> ? ? ? ?writel_relaxed(rate / CLOCK_TICK_RATE / 2 - 1, sirfsoc_timer_base + SIRFSOC_TIMER_DIV);
> ? ? ? ?writel_relaxed(0, sirfsoc_timer_base + SIRFSOC_TIMER_COUNTER_LO);
> ? ? ? ?writel_relaxed(0, sirfsoc_timer_base + SIRFSOC_TIMER_COUNTER_HI);
> @@ -217,6 +208,8 @@ static void __init sirfsoc_timer_init(void)
>
> ? ? ? ?BUG_ON(clocksource_register_hz(&sirfsoc_clocksource, CLOCK_TICK_RATE));
>
> + ? ? ? setup_sched_clock(sirfsoc_read_sched_clock, 32, CLOCK_TICK_RATE);
> +
> ? ? ? ?BUG_ON(setup_irq(sirfsoc_timer_irq.irq, &sirfsoc_timer_irq));
>
> ? ? ? ?sirfsoc_clockevent_init();
> --
> 1.7.7.1
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Thomas Rast @ 2012-01-17 8:45 UTC (permalink / raw)
To: Yves Goergen
Cc: Holger Hellmuth, Jeff King, Carlos Martín Nieto, git,
Erik Faye-Lund
In-Reply-To: <4F152767.9010104@unclassified.de>
Yves Goergen <nospam.list@unclassified.de> writes:
> On 16.01.2012 20:17 CE(S)T, Thomas Rast wrote:
>> If you work together with developers who have a case-sensitive FS (such
>> as Linux, or with the right options OS X), it's entirely possible that
>> this file exists in both spellings within the repository.
>
> Just FTR, I am working on the project alone, only on Windows with Visual
> Studio 2010 and I have two copies of the repository which I am
> occasionally synchronising via a USB memory stick when I work on the
> other machine. I have not pulled anything since the first issue came up
> on last Friday. No case-sensitive filesystem in the game.
Ok.
$ git ls-tree -r HEAD
100644 blob 5369994b8f905514661ee58b396dec31f8575a4d PosterWantsItCensored.Designer.cs
100644 blob 5369994b8f905514661ee58b396dec31f8575a4d PosterWantsItCensored.designer.cs
^ ^ ^
| | content hash
| type
file mode
That tells us that you have identical file contents in two files whose
names differ only in case.
This is important: Different name for git. Same name for OS. Same
contents.
That should also settle your remark at the end:
> I find it interesting to see that both files with the equal file name
> (like what the only relevant file system considers equal) have the same
> hash value. Does that qualify for your description of the "pretty bad bug"?
No, not a bug, just the same contents.
[And before you sue me for disclosing the SHA1 above: inferring the
contents of the file from the SHA1 is equivalent to breaking SHA1. If
anyone could, he'd already be busy writing a paper about it (or perhaps
working for the NSA).]
>> * You have the byte-for-byte identical file name listed twice in the
>> index. That would be a pretty bad bug.
>
> The index should usually be empty here, I guess. I really do not use
> it. No index interaction at all.
Please read up on the index before making such statements. You do use
the index, because it is a very important part of how git operates
whenever the operation also involves the worktree. And except in border
cases (new empty repo etc.) it should never be empty.
Your paste of
$ git status -s
[no output]
tells us that the index has *no differences* to your worktree, nor to
HEAD.
So in summary, the picture in your repository is:
* Somehow you got a different-only-in-case file pair into your
repository. It's already in HEAD. See below.
* The index and worktree are healthy and unchanged (w.r.t. HEAD) from
Git's POV. (This is possible despite the different-only-in-case files
because they have the same contents.)
For now I'm siding with Erik's theory
Erik Faye-Lund wrote:
} Very speculative comment: This might be a bug in TortoiseGit. Looking
} at the sources, it seems they are using libgit2 to mess around with
} the index; perhaps it's case-sensitivity code isn't as well tested as
} Git for Windows'?
It would also be interesting to know for how long this problem has
existed. You can search for the offending commit with something like
git log --name-status --diff-filter=A -- "PosterWantsItCensored.*"
which should normally give you just one or two commits, namely the
one(s) that introduced the two files.
As for the fix, there are two-and-two-thirds cases. First I'd like to
point out, however, that I have no idea how core.ignoreCase interacts
with rm --cached. I'm assuming you have to set it to 'false' for the
recipes below to work. Erik or Peff may correct me. You should set it
to 'true' again for real work.
Case 1: The commit that introduced the second spelling is HEAD
In this case you're sort of lucky because it's easy to fix. You can
do
git rm --cached PosterWantsItCensored.designer.cs
to get rid of the spelling you do not want. Then run
git status -s
again to verify that it did the right thing; it should say
D PosterWantsItCensored.designer.cs
where it's important that a) the other spelling does *not* show up in
the list anywhere and b) the D is in the leftmost column. Once you
have verified this, run
git commit --amend
to fix HEAD.
Case 2a: The commit that introduced it is older, but you don't care if
you cannot sanely checkout old commits
This is the case that I personally would never choose, since I care
about history, but for completeness: proceed as for case 1, except at
the end run
git commit # no --amend
and write a nice message saying that you fixed the
different-only-in-case issue.
Case 2b: The commit that introduced it is older, but history since its
parent has been linear (use gitk or some such to establish
this)
First run
git log --full-history --oneline -- "PosterWantsItCensored.*"
to see which commits touched the file. Let C be the SHA1 (or a unique
prefix) of the earliest commit that contains
PosterWantsItCensored.designer.cs (i.e., the wrong spelling) as
established earlier. Then run
git rebase -i C^
(That's right, the SHA1 of C and then a hat.)
In the editor that pops up, change 'pick' to 'edit' on every line that
shows a SHA1 you found in the preceding git-log command. Save and
exit.
Whenever rebase stops to let you edit (you can tell by the advice
messages it gives you), run
git ls-tree HEAD -- PosterWantsItCensored.designer.cs PosterWantsItCensored.Designer.cs
and check whether the SHA1s are different. Judging by what you said
they should always be the same (otherwise please come back for more
advice). You can then again do something very similar to Case 1 to
the commit you're editing, like
git rm --cached PosterWantsItCensored.designer.cs
git commit --amend
and finally
git rebase --continue
to edit the next commit. Repeat until the rebase is complete.
Case 2c: History wasn't linear since C; or you're just lazy and have a
good backup
The all-safeties-off, please-fix-it-for-me version goes
git filter-branch --tag-name-filter cat --index-filter '
git rm --ignore-unmatch --cached PosterWantsItCensored.designer.cs
' -- --all
I'm dead serious about the safeties off. You have been warned.
I have not tested most of this because it would simply take even more
time than writing an essay-length email. If something fails or got you
confused, paste everything you did and the full output again so we can
establish what happened.
All sub-items of case 2 rewrite history. You will have to force the
push to your "hub" repository that you use to exchange history, and you
may have to reset or rebase in the other repository. Read e.g. the
'recovering from upstream rebase' section in man git-rebase.
> (What a mess it would be if I committed something different than my
> working directory, however that works.)
You should really read up on this, e.g.
http://tomayko.com/writings/the-thing-about-git
AFAIK everyone who groks the feature uses it daily.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Updated btrfs/crypto snappy interface ready for merging
From: Li Zefan @ 2012-01-17 8:44 UTC (permalink / raw)
To: Chris Mason, Andi Kleen, linux-kernel, linux-btrfs
In-Reply-To: <20120116135442.GA28487@shiny>
21:54, Chris Mason wrote:
> On Thu, Jan 12, 2012 at 04:28:47PM -0800, Andi Kleen wrote:
>> Here's a slightly updated version of the BTRFS snappy interface.
>> snappy is a faster compression algorithm that provides similar
>> compression as LZO, but generally better performance.
>
> Thanks Andi, I've queued this up to a btrfs snappy branch. I put the
> commits against 3.2 instead of 3.3 though so people could try it out.
>
> The only problem I've hit is that snappy is failing xfstests number 135.
> It's reproducible on an empty FS. Could you please take a look?
>
It's because decompressing inline extents always fails. I've fixed it
and will send the patch out in a new mail thread.
But seems there's bug in lib snappy code, which makes the decompressed
data doesn't quite match the original data.
Simply copy a file to a btrfs filesystem with snappy enabled, and clear
page cache, and check the file:
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License (not later!)
+ * License as published by the Free ftwaware Foundation;
+ * version 2.1 of the censnse (not later!)
*
- * This program is distributed in the hope that it will be useful,
+ * is program i 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 Lesser General Public License for more details.
+ * GNU Lesser General Publicicenense for more details.
*
* You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not, write to the Free Software
+ * License along withhis progogram; if not, write to theree e Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: [dm-crypt] luksFormat library API doesnt seem to work with large keyfiles.
From: Milan Broz @ 2012-01-17 8:44 UTC (permalink / raw)
To: .. ink ..; +Cc: dm-crypt
In-Reply-To: <CAFnMBaT12UmzJZ+wCUNmwa1XsgdjiYxfQc+Pkj6V3sW=rFqimg@mail.gmail.com>
On 01/17/2012 09:05 AM, .. ink .. wrote:
> using cryptsetup 1.4.1
>
> test case below.
(please also read examples in docs/examples)
> key1 keyfile is a text file with 64 characters in it.
> key.cr <http://key.cr> is a 4.3MB mp3 file.
...
> status = crypt_keyslot_add_by_volume_key( cd,CRYPT_ANY_SLOT,NULL,32,c,strlen( c ) );
I guess strlen(c) is wrong, it will stop on the first zero (mp3 is binary data, not C string).
What about use st.st_size here?
About limits - there is default/compiled one but you can always override
it through API, exactly as you did above.
(Also see cryptsetup --help - "Default compiled-in keyfile parameters", you have
to override keyfile size using --keyfile-size option if it is over compiled-in limit
in CLI command.)
Milan
^ permalink raw reply
* Re: [BUG] TASK_DEAD task is able to be woken up in special condition
From: Yasunori Goto @ 2012-01-17 8:40 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Oleg Nesterov, Ingo Molnar, Hiroyuki KAMEZAWA, Motohiro Kosaki,
Linux Kernel ML
In-Reply-To: <1326721082.2442.234.camel@twins>
> On Mon, 2012-01-16 at 20:51 +0900, Yasunori Goto wrote:
>
> > try_to_wake_up() has a problem which may change status from TASK_DEAD to
> > TASK_RUNNING in race condition with SMI or guest environment of virtual
> > machine. (See: https://lkml.org/lkml/2011/12/21/523)
> > As a result, exited task is scheduled() again and panic occurs.
> >
> > By this patch, do_exit() waits for releasing task->pi_lock which is used
> > in try_to_wake_up(). It guarantees the task becomes TASK_DEAD after
> > waking up.
>
>
> This Changelog isn't very good. Please spell out the problem instead of
> referring to it so that people using git-blame and the like don't then
> have to go look up some (possibly non-existent) web-resource.
Ahh, Ok.
I rewrote the description and comment in patch.
Please check them.
-----
try_to_wake_up() has a problem which may change status from TASK_DEAD to
TASK_RUNNING in race condition with SMI or guest environment of virtual
machine. As a result, exited task is scheduled() again and panic occurs.
Here is the sequence how it occurs.
----------------------------------+-----------------------------
|
CPU A | CPU B
----------------------------------+-----------------------------
TASK A calls exit()....
do_exit()
exit_mm()
down_read(mm->mmap_sem);
rwsem_down_failed_common()
set TASK_UNINTERRUPTIBLE
set waiter.task <= task A
list_add to sem->wait_list
:
raw_spin_unlock_irq()
(I/O interruption occured)
__rwsem_do_wake(mmap_sem)
list_del(&waiter->list);
waiter->task = NULL
wake_up_process(task A)
try_to_wake_up()
(task is still
TASK_UNINTERRUPTIBLE)
p->on_rq is still 1.)
ttwu_do_wakeup()
(*A)
:
(I/O interruption handler finished)
if (!waiter.task)
schedule() is not called
due to waiter.task is NULL.
tsk->state = TASK_RUNNING
:
check_preempt_curr();
:
task->state = TASK_DEAD
(*B)
<--- set TASK_RUNNING (*C)
schedule()
(exit task is running again)
BUG_ON() is called!
--------------------------------------------------------
The execution time between (*A) and (*B) is usually very short,
because the interruption is disabled, and setting TASK_RUNNING at (*C)
must be executed before setting TASK_DEAD.
HOWEVER, if SMI is interrupted between (*A) and (*B),
(*C) is able to execute AFTER setting TASK_DEAD!
Then, exited task is scheduled again, and BUG_ON() is called....
If the system works on guest system of virtual machine, the time
between (*A) and (*B) may be also long due to scheduling of hypervisor,
and same phenomenon can occur.
By this patch, do_exit() waits for releasing task->pi_lock which is used
in try_to_wake_up(). It guarantees the task becomes TASK_DEAD after
waking up.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
---
kernel/exit.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
Index: linux-3.2/kernel/exit.c
===================================================================
--- linux-3.2.orig/kernel/exit.c
+++ linux-3.2/kernel/exit.c
@@ -1038,6 +1038,22 @@ NORET_TYPE void do_exit(long code)
preempt_disable();
exit_rcu();
+
+ /*
+ * The setting of TASK_RUNNING by try_to_wake_up() may be delayed
+ * when the following two conditions become true.
+ * - There is race condition of mmap_sem (It is acquired by
+ * exit_mm()), and
+ * - SMI occurs before setting TASK_RUNINNG.
+ * (or hypervisor of virtual machine switches to other guest)
+ * As a result, we may become TASK_RUNNING after becoming TASK_DEAD
+ *
+ * To avoid it, we have to wait for releasing tsk->pi_lock which
+ * is held by try_to_wake_up()
+ */
+ smp_mb();
+ raw_spin_unlock_wait(&tsk->pi_lock);
+
/* causes final put_task_struct in finish_task_switch(). */
tsk->state = TASK_DEAD;
schedule();
-----
--
Yasunori Goto
^ permalink raw reply
* [CONSOLIDATED PULL 61/62] openssl-0.9.8: Update to 0.9.8s
From: Saul Wold @ 2012-01-17 8:32 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1326786989.git.sgw@linux.intel.com>
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4108
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4109
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4576
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4577
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4619
[YOCTO #1904]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
.../configure-targets.patch | 0
.../debian/ca.patch | 0
.../debian/config-hurd.patch | 0
.../debian/debian-targets.patch | 0
.../debian/engines-path.patch | 0
.../debian/kfreebsd-pipe.patch | 0
.../debian/make-targets.patch | 0
.../debian/man-dir.patch | 0
.../debian/man-section.patch | 0
.../debian/no-rpath.patch | 0
.../debian/no-symbolic.patch | 0
.../debian/perl-path.diff | 0
.../debian/pic.patch | 0
.../debian/pkg-config.patch | 0
.../debian/rc4-amd64.patch | 0
.../debian/rehash-crt.patch | 0
.../debian/rehash_pod.patch | 0
.../debian/series | 0
.../debian/shared-lib-ext.patch | 0
.../debian/stddef.patch | 0
.../debian/version-script.patch | 0
.../parallel-make-fix.patch | 0
.../shared-libs.patch | 0
.../{openssl_0.9.8r.bb => openssl_0.9.8s.bb} | 8 ++++----
24 files changed, 4 insertions(+), 4 deletions(-)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/configure-targets.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/ca.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/config-hurd.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/debian-targets.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/engines-path.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/kfreebsd-pipe.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/make-targets.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/man-dir.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/man-section.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/no-rpath.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/no-symbolic.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/perl-path.diff (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/pic.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/pkg-config.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/rc4-amd64.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/rehash-crt.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/rehash_pod.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/series (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/shared-lib-ext.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/stddef.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/debian/version-script.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/parallel-make-fix.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-0.9.8r => openssl-0.9.8s}/shared-libs.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl_0.9.8r.bb => openssl_0.9.8s.bb} (87%)
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/configure-targets.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/configure-targets.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/configure-targets.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/configure-targets.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/ca.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/ca.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/ca.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/ca.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/config-hurd.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/config-hurd.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/config-hurd.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/config-hurd.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/debian-targets.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/debian-targets.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/debian-targets.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/debian-targets.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/engines-path.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/engines-path.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/engines-path.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/engines-path.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/kfreebsd-pipe.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/kfreebsd-pipe.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/kfreebsd-pipe.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/kfreebsd-pipe.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/make-targets.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/make-targets.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/make-targets.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/make-targets.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/man-dir.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/man-dir.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/man-dir.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/man-dir.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/man-section.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/man-section.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/man-section.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/man-section.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/no-rpath.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/no-rpath.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/no-rpath.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/no-rpath.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/no-symbolic.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/no-symbolic.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/no-symbolic.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/no-symbolic.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/perl-path.diff b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/perl-path.diff
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/perl-path.diff
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/perl-path.diff
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/pic.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/pic.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/pic.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/pic.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/pkg-config.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/pkg-config.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/pkg-config.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/pkg-config.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/rc4-amd64.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/rc4-amd64.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/rc4-amd64.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/rc4-amd64.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/rehash-crt.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/rehash-crt.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/rehash-crt.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/rehash-crt.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/rehash_pod.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/rehash_pod.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/rehash_pod.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/rehash_pod.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/series b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/series
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/series
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/series
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/shared-lib-ext.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/shared-lib-ext.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/shared-lib-ext.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/shared-lib-ext.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/stddef.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/stddef.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/stddef.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/stddef.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/version-script.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/version-script.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/debian/version-script.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/debian/version-script.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/parallel-make-fix.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/parallel-make-fix.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/parallel-make-fix.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/parallel-make-fix.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-0.9.8r/shared-libs.patch b/meta/recipes-connectivity/openssl/openssl-0.9.8s/shared-libs.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-0.9.8r/shared-libs.patch
rename to meta/recipes-connectivity/openssl/openssl-0.9.8s/shared-libs.patch
diff --git a/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb b/meta/recipes-connectivity/openssl/openssl_0.9.8s.bb
similarity index 87%
rename from meta/recipes-connectivity/openssl/openssl_0.9.8r.bb
rename to meta/recipes-connectivity/openssl/openssl_0.9.8s.bb
index 4c6cad3..74892c1 100644
--- a/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb
+++ b/meta/recipes-connectivity/openssl/openssl_0.9.8s.bb
@@ -1,6 +1,6 @@
require openssl.inc
-PR = "r7"
+PR = "r0"
SRC_URI += "file://debian/ca.patch \
file://debian/config-hurd.patch;apply=no \
file://debian/debian-targets.patch \
@@ -21,11 +21,11 @@ SRC_URI += "file://debian/ca.patch \
file://debian/version-script.patch \
file://debian/perl-path.diff"
-SRC_URI[md5sum] = "0352932ea863bc02b056cda7c9ac5b79"
-SRC_URI[sha256sum] = "42b2368f786b05ed3be846838dce126b4e8e3dba8fb2e0ce83102df28c102fad"
-
SRC_URI += "file://configure-targets.patch \
file://shared-libs.patch \
file://parallel-make-fix.patch"
+SRC_URI[md5sum] = "fbf71e8e050bc1ec290b7468bab1a76e"
+SRC_URI[sha256sum] = "edc9639beaf2d5e239d8e5c9d2fe1959e6726a5d7f8ab8430613835f4623f9ba"
+
BBCLASSEXTEND = "native nativesdk"
--
1.7.6.5
^ permalink raw reply related
* [CONSOLIDATED PULL 62/62] openssl-1.0.0: Update to 1.0.0e and fix QA Warning
From: Saul Wold @ 2012-01-17 8:32 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1326786989.git.sgw@linux.intel.com>
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4108
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4576
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4577
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4619
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-0027
[YOCTO #1905]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
.../configure-targets.patch | 0
.../debian/c_rehash-compat.patch | 0
.../debian/ca.patch | 0
.../debian/debian-targets.patch | 0
.../debian/make-targets.patch | 0
.../debian/man-dir.patch | 0
.../debian/man-section.patch | 0
.../debian/no-rpath.patch | 0
.../debian/no-symbolic.patch | 0
.../debian/pic.patch | 0
.../debian/pkg-config.patch | 0
.../debian/version-script.patch | 0
.../engines-install-in-libdir-ssl.patch | 0
.../oe-ldflags.patch | 0
.../openssl-fix-link.patch | 0
.../openssl_fix_for_x32.patch | 0
.../shared-libs.patch | 0
.../{openssl_1.0.0e.bb => openssl_1.0.0f.bb} | 8 ++++----
18 files changed, 4 insertions(+), 4 deletions(-)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/configure-targets.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/debian/c_rehash-compat.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/debian/ca.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/debian/debian-targets.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/debian/make-targets.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/debian/man-dir.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/debian/man-section.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/debian/no-rpath.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/debian/no-symbolic.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/debian/pic.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/debian/pkg-config.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/debian/version-script.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/engines-install-in-libdir-ssl.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/oe-ldflags.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/openssl-fix-link.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/openssl_fix_for_x32.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.0e => openssl-1.0.0f}/shared-libs.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl_1.0.0e.bb => openssl_1.0.0f.bb} (84%)
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/configure-targets.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/configure-targets.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/configure-targets.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/configure-targets.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/c_rehash-compat.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/c_rehash-compat.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/c_rehash-compat.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/c_rehash-compat.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/ca.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/ca.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/ca.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/ca.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/debian-targets.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/debian-targets.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/debian-targets.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/debian-targets.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/make-targets.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/make-targets.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/make-targets.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/make-targets.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/man-dir.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/man-dir.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/man-dir.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/man-dir.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/man-section.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/man-section.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/man-section.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/man-section.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/no-rpath.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/no-rpath.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/no-rpath.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/no-rpath.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/no-symbolic.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/no-symbolic.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/no-symbolic.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/no-symbolic.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/pic.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/pic.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/pic.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/pic.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/pkg-config.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/pkg-config.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/pkg-config.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/pkg-config.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/version-script.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/version-script.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/debian/version-script.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/debian/version-script.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/engines-install-in-libdir-ssl.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/engines-install-in-libdir-ssl.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/engines-install-in-libdir-ssl.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/engines-install-in-libdir-ssl.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/oe-ldflags.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/oe-ldflags.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/oe-ldflags.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/oe-ldflags.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/openssl-fix-link.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/openssl-fix-link.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/openssl-fix-link.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/openssl-fix-link.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/openssl_fix_for_x32.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/openssl_fix_for_x32.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/openssl_fix_for_x32.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/openssl_fix_for_x32.patch
diff --git a/meta/recipes-connectivity/openssl/openssl-1.0.0e/shared-libs.patch b/meta/recipes-connectivity/openssl/openssl-1.0.0f/shared-libs.patch
similarity index 100%
rename from meta/recipes-connectivity/openssl/openssl-1.0.0e/shared-libs.patch
rename to meta/recipes-connectivity/openssl/openssl-1.0.0f/shared-libs.patch
diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.0e.bb b/meta/recipes-connectivity/openssl/openssl_1.0.0f.bb
similarity index 84%
rename from meta/recipes-connectivity/openssl/openssl_1.0.0e.bb
rename to meta/recipes-connectivity/openssl/openssl_1.0.0f.bb
index e29740b..f3404d6 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.0.0e.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.0.0f.bb
@@ -6,7 +6,7 @@ DEPENDS += "ocf-linux"
CFLAG += "-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS"
-PR = "${INC_PR}.2"
+PR = "${INC_PR}.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=f9a8f968107345e0b75aa8c2ecaa7ec8"
@@ -32,15 +32,15 @@ SRC_URI += "file://configure-targets.patch \
file://openssl_fix_for_x32.patch \
"
-SRC_URI[md5sum] = "7040b89c4c58c7a1016c0dfa6e821c86"
-SRC_URI[sha256sum] = "e361dc2775733fb84de7b5bf7b504778b772869e8f7bfac0b28b935cbf7380f7"
+SRC_URI[md5sum] = "e358705fb4a8827b5e9224a73f442025"
+SRC_URI[sha256sum] = "faf1eab0ef85fd6c3beca271c356b31b5cc831e2c6b7f23cf672e7ab4680fde1"
PACKAGES =+ " \
${PN}-engines \
${PN}-engines-dbg \
"
-FILES_${PN}-engines = "${libdir}/ssl/engines/*.so"
+FILES_${PN}-engines = "${libdir}/ssl/engines/*.so ${libdir}/engines"
FILES_${PN}-engines-dbg = "${libdir}/ssl/engines/.debug"
PARALLEL_MAKEINST = ""
--
1.7.6.5
^ permalink raw reply related
* [CONSOLIDATED PULL 60/62] tcl: PR bump for eglibc update
From: Saul Wold @ 2012-01-17 8:32 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1326786989.git.sgw@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
meta/recipes-devtools/tcltk/tcl_8.5.11.bb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/tcltk/tcl_8.5.11.bb b/meta/recipes-devtools/tcltk/tcl_8.5.11.bb
index 146021a..0b3bc5b 100644
--- a/meta/recipes-devtools/tcltk/tcl_8.5.11.bb
+++ b/meta/recipes-devtools/tcltk/tcl_8.5.11.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://../license.terms;md5=a47a9be26d03f925fc1fbd2784f27e11
file://../win/license.terms;md5=a47a9be26d03f925fc1fbd2784f27e11 \
"
-PR = "r2"
+PR = "r3"
BASE_SRC_URI = "${SOURCEFORGE_MIRROR}/tcl/tcl${PV}-src.tar.gz \
file://tcl-add-soname.patch"
--
1.7.6.5
^ permalink raw reply related
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.