* Re: DeviceTree and children devices
From: Grant Likely @ 2011-10-24 8:23 UTC (permalink / raw)
To: balbi; +Cc: Linux Kernel Mailing List, Linux USB Mailing List
In-Reply-To: <20111024081244.GD15288@legolas.emea.dhcp.ti.com>
On Mon, Oct 24, 2011 at 10:12 AM, Felipe Balbi <balbi@ti.com> wrote:
> On Mon, Oct 24, 2011 at 09:58:39AM +0200, Grant Likely wrote:
>> On Mon, Oct 24, 2011 at 9:49 AM, Felipe Balbi <balbi@ti.com> wrote:
>> > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> > index ed5a6d3..172d4a9 100644
>> > --- a/drivers/of/platform.c
>> > +++ b/drivers/of/platform.c
>> > @@ -204,7 +204,12 @@ struct platform_device *of_platform_device_create_pdata(
>> > #if defined(CONFIG_MICROBLAZE)
>> > dev->archdata.dma_mask = 0xffffffffUL;
>> > #endif
>> > - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> > +
>> > + if (parent)
>> > + dma_set_coherent_mask(&dev->dev, parent->coherent_dma_mask);
>> > + else
>> > + dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
>> > +
>>
>> Right, this does need to be fixed. The existing code just matched
>> what the historical powerpc code did, but it is certainly not correct.
>
> should I send patch above correctly ? Or do you want to also solve
> 32-bit coherent mask altogether ? What are your plans for that ? Add a
> separate property to pass coherent_mask size (32-bit, 64-bit, etc) ?
i don't know. I'm not the expert on how the coherent mask should be
set. Your patch does look sane as a starting point, but it bears
looking at by someone more cluefull than me. In particular, someone
should investigate if the dma mask can be calculated from a dma-ranges
property.
g.
^ permalink raw reply
* Re: Snapshot rollback
From: dima @ 2011-10-24 8:24 UTC (permalink / raw)
To: linux-btrfs
In-Reply-To: <CAG1y0sfmnD8W7an-7HicwfH0HuzJA4wnOLq90qn5iTJmEs4v0w@mail.gmail.com>
Fajar A. Nugraha <list <at> fajar.net> writes:
> A problem with that, though, if you decide to put /boot on btrfs as
> well. Grub uses the default subvolume to determine paths (for kernel,
> initrd, etc). A workaround is to manually create and manage your
> grub.cfg (or create and use a manual-managed include file, like
> custom-top.cfg, that gets parsed before the automatically created
> entries).
Oops, sorry, I was incorrect of course. Thanks Fajar.
I do have /boot in my subvolid=0 because bootloaders can't read inside
subvolumes (other than the default) as far as I understand.
And I just bind /boot through fstab.
^ permalink raw reply
* Re: [PATCH] v4l: mt9p031/mt9t001: Use i2c_smbus_{read|write}_word_swapped()
From: Jonathan Cameron @ 2011-10-24 8:26 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-media, khali, kernel
In-Reply-To: <201110221057.54573.laurent.pinchart@ideasonboard.com>
On 10/22/11 09:57, Laurent Pinchart wrote:
> The MT9P031 and MT9T001 sensors transfer 16-bit data on the I2C bus in
> swapped order. Let the I2C core handle byte order by using the
> i2c_smbus_{read|write}_word_swapped() functions.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
> ---
> drivers/media/video/mt9p031.c | 5 ++---
> drivers/media/video/mt9t001.c | 5 ++---
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
> index 5cfa39f..aa01c4b 100644
> --- a/drivers/media/video/mt9p031.c
> +++ b/drivers/media/video/mt9p031.c
> @@ -131,13 +131,12 @@ static struct mt9p031 *to_mt9p031(struct v4l2_subdev *sd)
>
> static int mt9p031_read(struct i2c_client *client, u8 reg)
> {
> - s32 data = i2c_smbus_read_word_data(client, reg);
> - return data < 0 ? data : be16_to_cpu(data);
> + return i2c_smbus_read_word_swapped(client, reg);
> }
>
> static int mt9p031_write(struct i2c_client *client, u8 reg, u16 data)
> {
> - return i2c_smbus_write_word_data(client, reg, cpu_to_be16(data));
> + return i2c_smbus_write_word_swapped(client, reg, data);
> }
>
> static int mt9p031_set_output_control(struct mt9p031 *mt9p031, u16 clear,
> diff --git a/drivers/media/video/mt9t001.c b/drivers/media/video/mt9t001.c
> index cac1416..2ea6a08 100644
> --- a/drivers/media/video/mt9t001.c
> +++ b/drivers/media/video/mt9t001.c
> @@ -132,13 +132,12 @@ static inline struct mt9t001 *to_mt9t001(struct v4l2_subdev *sd)
>
> static int mt9t001_read(struct i2c_client *client, u8 reg)
> {
> - s32 data = i2c_smbus_read_word_data(client, reg);
> - return data < 0 ? data : be16_to_cpu(data);
> + return i2c_smbus_read_word_swapped(client, reg);
> }
>
> static int mt9t001_write(struct i2c_client *client, u8 reg, u16 data)
> {
> - return i2c_smbus_write_word_data(client, reg, cpu_to_be16(data));
> + return i2c_smbus_write_word_swapped(client, reg, data);
> }
>
> static int mt9t001_set_output_control(struct mt9t001 *mt9t001, u16 clear,
^ permalink raw reply
* Re: [PATCH v2 0/9] serial: samsung: rework clock lookup and add device tree support
From: Kukjin Kim @ 2011-10-24 8:27 UTC (permalink / raw)
To: Thomas Abraham, Greg KH
Cc: linux-serial, devicetree-discuss, kgene.kim, grant.likely,
linux-samsung-soc, ben-linux, linux-arm-kernel, alan
In-Reply-To: <1318241285-23568-1-git-send-email-thomas.abraham@linaro.org>
On 10/10/11 12:07, Thomas Abraham wrote:
> Changes since v1:
> - Included the missing dt bindings documentation in the last patch.
> - Rebased and tested with linux 3.1-rc9 on linux-samsung-soc tree.
> - Commit messages are modified to be elaborate.
> - No changes in code.
>
>
> This patchset reworks the lookup of parent clocks for baud rate generator in
> the uart controller and adds support for device tree based discovery for the
> uart controller.
>
> The Samsung uart driver was dependent on the clock names supplied in the
> platform data. This dependency had to be first removed to add device tree based
> discovery support for Samsung uart driver. In the process of reworking the clock
> lookup logic, several changes had to be made which in turn made parts of the
> driver redundant and such portions of the driver have been removed in this
> patchset. As a result, all the SoC specific extensions have been deleted.
>
> Patch 1 modifies the driver to keep a copy of the location of the platform data
> in the driver's private data. This makes device tree support addition
> non-intrusive.
>
> Patch 2 moves the complicated clock divider handling for fclk source clock for
> s3c2440 SoC into platform code. The fclk clock can be easily managed by
> representing it as a clock in the platform code. fclk clock handling was
> specific to s3c2440 and moving this out of the driver makes the rest of the
> clock handling in the driver almost identical for all SoC's supported by the
> driver.
>
> Patch 3 modifies the driver to lookup source clocks for baud rate generator
> by using generic clock names. The generic clock name used by the driver is
> 'clk_uart_baud' appended with the parent number of the clock. For instance,
> the second parent clock source option for baud rate generator is named as
> 'clk_uart_baud2'.
>
> The driver stops depending on the set_clock and get_clock callbacks in the
> SoC specific extensions. Instead, the driver is modified to lookup parent
> clock rates and decide/calculate the best parent clock source for the baud
> rate generator (best clock would have the least delta when compared to buad
> rate requested).
>
> In this process, four new members are added in the driver's private data
> structure. The 'def_clk_sel' member is a platform set bit-value that specifies
> the possible parents that the driver is allowed to use for baud rate clock.
> A bit set at a particular bit position selects that parent clock source.
> Example: If bit number 2 is set in 'def_clk_sel', then parent clock source '2'
> can be a possible parent clock for baud rate generator. The 'num_clks'
> is the number of possible parent clocks that the SoC supports. The
> 'clksel_mask' and 'clksel_shift' members are used to operate on the parent clock
> selection bit field int the uart controller's contol register.
>
> Patch 4 removes all uses and instances of 'struct s3c24xx_uart_clksrc'. This
> structure was used to pass source clock 'names' between platform code, driver
> and SoC specific extensions. By moving away from using platform specified clock
> names in the driver, all uses and instances of 'struct s3c24xx_uart_clksrc'
> is removed.
>
> Patch 5 removes all the SoC specific get_clksrc and set_clksrc callbacks. These
> callbacks were using SoC specific clock names to communicate the clock to be
> set or retrieved. These callbacks are removed as they are no longer required.
>
> Patch 6 reworks the uart clocks in platform code of all Samsung SoC's. The
> driver would use generic clock names and this patch creates aliases to uart
> clocks with generic clock names as the alias name.
>
> Patch 7 merges all the SoC specific port reset functions into one common port
> reset function and moves the common function into the common Samsung uart
> driver. All the SoC specific port reset functions perform the same operation
> allowing all of them to be converged.
>
> Patch 8 collapses all the SoC specific probe functions and associated driver
> private data into the Samsung common uart driver. With get_clksrc, set_clksrc
> and reset_port functions removed from SoC specific extensions, all the remains
> in those extensions is the probe function along with SoC specific driver data.
> These are merged into the common Samsung uart driver and all the SoC specific
> extensions are deleted.
>
> Patch 9 adds device tree based discovery support for the uart driver.
>
>
> This patchset is based on the following tree
> https://github.com/kgene/linux-samsung.git branch: for-next
>
> with the following two patches applied
> [PATCH] serial: samsung: Add unified interrupt handler for s3c64xx and later SoC's
> [PATCH] ARM: SAMSUNG: Remove uart irq handling from plaform code
>
> and tested on the following boards.
> SMDK2440, SMDK2416, SMDK6410, SMDK6440, SMDK6450, SMDKC100, SMDKV210, SMDKV310.
>
> This patchset has dependency on the following patchset:
> [PATCH V2 0/2] Add a common macro for creating struct clk_lookup entries
>
>
> Thomas Abraham (9):
> serial: samsung: Keep a copy of the location of platform data in driver's private data
> serial: samsung: move handling of fclk/n clock to platform code
> serial: samsung: switch to clkdev based clock lookup
> serial: samsung: remove struct 's3c24xx_uart_clksrc' and all uses of it
> serial: samsung: remove all uses of get_clksrc and set_clksrc
> arm: samsung: register uart clocks to clock lookup list
> serial: samsung: merge all SoC specific port reset functions
> serial: samsung: merge probe() function from all SoC specific extensions
> serial: samsung: add device tree support
>
> .../devicetree/bindings/serial/samsung_uart.txt | 14 +
> arch/arm/mach-exynos4/clock.c | 106 ++--
> arch/arm/mach-exynos4/init.c | 21 +-
> arch/arm/mach-s3c2410/mach-bast.c | 22 -
> arch/arm/mach-s3c2410/mach-vr1000.c | 24 -
> arch/arm/mach-s3c2410/s3c2410.c | 6 +
> arch/arm/mach-s3c2412/clock.c | 7 +
> arch/arm/mach-s3c2440/clock.c | 44 ++
> arch/arm/mach-s3c2440/mach-anubis.c | 22 +-
> arch/arm/mach-s3c2440/mach-at2440evb.c | 22 +-
> arch/arm/mach-s3c2440/mach-osiris.c | 24 +-
> arch/arm/mach-s3c2440/mach-rx1950.c | 18 +-
> arch/arm/mach-s3c2440/mach-rx3715.c | 19 +-
> arch/arm/mach-s3c64xx/clock.c | 37 +-
> arch/arm/mach-s5p64x0/clock-s5p6440.c | 32 +-
> arch/arm/mach-s5p64x0/clock-s5p6450.c | 32 +-
> arch/arm/mach-s5p64x0/init.c | 31 -
> arch/arm/mach-s5pc100/clock.c | 33 +-
> arch/arm/mach-s5pv210/clock.c | 107 ++--
> arch/arm/mach-s5pv210/init.c | 19 -
> arch/arm/plat-s3c24xx/s3c2443-clock.c | 23 +-
> arch/arm/plat-samsung/include/plat/regs-serial.h | 45 +-
> drivers/tty/serial/Kconfig | 45 +--
> drivers/tty/serial/Makefile | 5 -
> drivers/tty/serial/s3c2410.c | 115 ----
> drivers/tty/serial/s3c2412.c | 149 -----
> drivers/tty/serial/s3c2440.c | 178 ------
> drivers/tty/serial/s3c6400.c | 149 -----
> drivers/tty/serial/s5pv210.c | 158 -----
> drivers/tty/serial/samsung.c | 639 ++++++++++++--------
> drivers/tty/serial/samsung.h | 32 +-
> 31 files changed, 752 insertions(+), 1426 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/serial/samsung_uart.txt
> delete mode 100644 drivers/tty/serial/s3c2410.c
> delete mode 100644 drivers/tty/serial/s3c2412.c
> delete mode 100644 drivers/tty/serial/s3c2440.c
> delete mode 100644 drivers/tty/serial/s3c6400.c
> delete mode 100644 drivers/tty/serial/s5pv210.c
(Cc'ed Greg KH)
Looks good for me, and I need to get the ack from Greg before applying.
Greg, if you're ok, I'd like to send this series to upstream via Samsung
tree for supporting device tree because this touches a lot of arch/arm/
Samsung stuff. If any problems, please let me know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH v2 0/9] serial: samsung: rework clock lookup and add device tree support
From: Kukjin Kim @ 2011-10-24 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318241285-23568-1-git-send-email-thomas.abraham@linaro.org>
On 10/10/11 12:07, Thomas Abraham wrote:
> Changes since v1:
> - Included the missing dt bindings documentation in the last patch.
> - Rebased and tested with linux 3.1-rc9 on linux-samsung-soc tree.
> - Commit messages are modified to be elaborate.
> - No changes in code.
>
>
> This patchset reworks the lookup of parent clocks for baud rate generator in
> the uart controller and adds support for device tree based discovery for the
> uart controller.
>
> The Samsung uart driver was dependent on the clock names supplied in the
> platform data. This dependency had to be first removed to add device tree based
> discovery support for Samsung uart driver. In the process of reworking the clock
> lookup logic, several changes had to be made which in turn made parts of the
> driver redundant and such portions of the driver have been removed in this
> patchset. As a result, all the SoC specific extensions have been deleted.
>
> Patch 1 modifies the driver to keep a copy of the location of the platform data
> in the driver's private data. This makes device tree support addition
> non-intrusive.
>
> Patch 2 moves the complicated clock divider handling for fclk source clock for
> s3c2440 SoC into platform code. The fclk clock can be easily managed by
> representing it as a clock in the platform code. fclk clock handling was
> specific to s3c2440 and moving this out of the driver makes the rest of the
> clock handling in the driver almost identical for all SoC's supported by the
> driver.
>
> Patch 3 modifies the driver to lookup source clocks for baud rate generator
> by using generic clock names. The generic clock name used by the driver is
> 'clk_uart_baud' appended with the parent number of the clock. For instance,
> the second parent clock source option for baud rate generator is named as
> 'clk_uart_baud2'.
>
> The driver stops depending on the set_clock and get_clock callbacks in the
> SoC specific extensions. Instead, the driver is modified to lookup parent
> clock rates and decide/calculate the best parent clock source for the baud
> rate generator (best clock would have the least delta when compared to buad
> rate requested).
>
> In this process, four new members are added in the driver's private data
> structure. The 'def_clk_sel' member is a platform set bit-value that specifies
> the possible parents that the driver is allowed to use for baud rate clock.
> A bit set at a particular bit position selects that parent clock source.
> Example: If bit number 2 is set in 'def_clk_sel', then parent clock source '2'
> can be a possible parent clock for baud rate generator. The 'num_clks'
> is the number of possible parent clocks that the SoC supports. The
> 'clksel_mask' and 'clksel_shift' members are used to operate on the parent clock
> selection bit field int the uart controller's contol register.
>
> Patch 4 removes all uses and instances of 'struct s3c24xx_uart_clksrc'. This
> structure was used to pass source clock 'names' between platform code, driver
> and SoC specific extensions. By moving away from using platform specified clock
> names in the driver, all uses and instances of 'struct s3c24xx_uart_clksrc'
> is removed.
>
> Patch 5 removes all the SoC specific get_clksrc and set_clksrc callbacks. These
> callbacks were using SoC specific clock names to communicate the clock to be
> set or retrieved. These callbacks are removed as they are no longer required.
>
> Patch 6 reworks the uart clocks in platform code of all Samsung SoC's. The
> driver would use generic clock names and this patch creates aliases to uart
> clocks with generic clock names as the alias name.
>
> Patch 7 merges all the SoC specific port reset functions into one common port
> reset function and moves the common function into the common Samsung uart
> driver. All the SoC specific port reset functions perform the same operation
> allowing all of them to be converged.
>
> Patch 8 collapses all the SoC specific probe functions and associated driver
> private data into the Samsung common uart driver. With get_clksrc, set_clksrc
> and reset_port functions removed from SoC specific extensions, all the remains
> in those extensions is the probe function along with SoC specific driver data.
> These are merged into the common Samsung uart driver and all the SoC specific
> extensions are deleted.
>
> Patch 9 adds device tree based discovery support for the uart driver.
>
>
> This patchset is based on the following tree
> https://github.com/kgene/linux-samsung.git branch: for-next
>
> with the following two patches applied
> [PATCH] serial: samsung: Add unified interrupt handler for s3c64xx and later SoC's
> [PATCH] ARM: SAMSUNG: Remove uart irq handling from plaform code
>
> and tested on the following boards.
> SMDK2440, SMDK2416, SMDK6410, SMDK6440, SMDK6450, SMDKC100, SMDKV210, SMDKV310.
>
> This patchset has dependency on the following patchset:
> [PATCH V2 0/2] Add a common macro for creating struct clk_lookup entries
>
>
> Thomas Abraham (9):
> serial: samsung: Keep a copy of the location of platform data in driver's private data
> serial: samsung: move handling of fclk/n clock to platform code
> serial: samsung: switch to clkdev based clock lookup
> serial: samsung: remove struct 's3c24xx_uart_clksrc' and all uses of it
> serial: samsung: remove all uses of get_clksrc and set_clksrc
> arm: samsung: register uart clocks to clock lookup list
> serial: samsung: merge all SoC specific port reset functions
> serial: samsung: merge probe() function from all SoC specific extensions
> serial: samsung: add device tree support
>
> .../devicetree/bindings/serial/samsung_uart.txt | 14 +
> arch/arm/mach-exynos4/clock.c | 106 ++--
> arch/arm/mach-exynos4/init.c | 21 +-
> arch/arm/mach-s3c2410/mach-bast.c | 22 -
> arch/arm/mach-s3c2410/mach-vr1000.c | 24 -
> arch/arm/mach-s3c2410/s3c2410.c | 6 +
> arch/arm/mach-s3c2412/clock.c | 7 +
> arch/arm/mach-s3c2440/clock.c | 44 ++
> arch/arm/mach-s3c2440/mach-anubis.c | 22 +-
> arch/arm/mach-s3c2440/mach-at2440evb.c | 22 +-
> arch/arm/mach-s3c2440/mach-osiris.c | 24 +-
> arch/arm/mach-s3c2440/mach-rx1950.c | 18 +-
> arch/arm/mach-s3c2440/mach-rx3715.c | 19 +-
> arch/arm/mach-s3c64xx/clock.c | 37 +-
> arch/arm/mach-s5p64x0/clock-s5p6440.c | 32 +-
> arch/arm/mach-s5p64x0/clock-s5p6450.c | 32 +-
> arch/arm/mach-s5p64x0/init.c | 31 -
> arch/arm/mach-s5pc100/clock.c | 33 +-
> arch/arm/mach-s5pv210/clock.c | 107 ++--
> arch/arm/mach-s5pv210/init.c | 19 -
> arch/arm/plat-s3c24xx/s3c2443-clock.c | 23 +-
> arch/arm/plat-samsung/include/plat/regs-serial.h | 45 +-
> drivers/tty/serial/Kconfig | 45 +--
> drivers/tty/serial/Makefile | 5 -
> drivers/tty/serial/s3c2410.c | 115 ----
> drivers/tty/serial/s3c2412.c | 149 -----
> drivers/tty/serial/s3c2440.c | 178 ------
> drivers/tty/serial/s3c6400.c | 149 -----
> drivers/tty/serial/s5pv210.c | 158 -----
> drivers/tty/serial/samsung.c | 639 ++++++++++++--------
> drivers/tty/serial/samsung.h | 32 +-
> 31 files changed, 752 insertions(+), 1426 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/serial/samsung_uart.txt
> delete mode 100644 drivers/tty/serial/s3c2410.c
> delete mode 100644 drivers/tty/serial/s3c2412.c
> delete mode 100644 drivers/tty/serial/s3c2440.c
> delete mode 100644 drivers/tty/serial/s3c6400.c
> delete mode 100644 drivers/tty/serial/s5pv210.c
(Cc'ed Greg KH)
Looks good for me, and I need to get the ack from Greg before applying.
Greg, if you're ok, I'd like to send this series to upstream via Samsung
tree for supporting device tree because this touches a lot of arch/arm/
Samsung stuff. If any problems, please let me know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* Re: [PATCH] staging:iio:treewide only use shared to decide on interfaces
From: Lars-Peter Clausen @ 2011-10-24 8:30 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: linux-iio, michael.hennerich, device-drivers-devel
In-Reply-To: <1319211579-14367-2-git-send-email-jic23@cam.ac.uk>
On 10/21/2011 05:39 PM, Jonathan Cameron wrote:
> Internally the fact that say scale is shared across channels is
> actually of remarkably little interest. Hence lets not store it.
> Numerous devices have weird combinations of channels sharing
> scale anyway so it is not as though this was really telling
> us much. Note however that we do still use the shared sysfs
> attrs thus massively reducing the number of attrs in complex
> drivers.
>
> Side effect is that certain drivers that were abusing this
> (mostly my work) needed to do a few more checks on what the
> channel they are being queried on actually is.
>
> This is also helpful for in kernel interfaces where we
> just want to query the scale and don't care whether it
> is shared with other channels or not.
>
> Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Hi
Seems to work. I think it makes sense to submit this one and the other,
which removes the bitmask addressing, together. Will you take care of this?
Thanks,
- Lars
^ permalink raw reply
* Re: Vanilla-Kernel 3 - page allocation failure
From: Eric Dumazet @ 2011-10-24 8:29 UTC (permalink / raw)
To: p.herz; +Cc: David Rientjes, Andi Kleen, s.priebe, linux-kernel
In-Reply-To: <4EA51F9B.7090806@profihost.ag>
Le lundi 24 octobre 2011 à 10:19 +0200, Philipp Herz - Profihost AG a
écrit :
> Currently i can not provide any further information, 'cause server has
> been restarted.
>
> What exactly are you looking for?
A dmesg for 2.6.32 is OK, I look for :
- memory layout (tg3 has workarounds for 4G crossing),
- and exact tg3 chip, tg3 messages...
^ permalink raw reply
* Re: lvs-users mailing list and archive dead?
From: Graeme Fowler @ 2011-10-24 8:32 UTC (permalink / raw)
To: Tomasz Chmielewski; +Cc: lvs-devel
In-Reply-To: <4EA4709A.1050501@wpkg.org>
On Sun, 2011-10-23 at 21:52 +0200, Tomasz Chmielewski wrote:
> I'm not able to resolve names from it from a largish German hosting
> provider, Hetzner.
Can you please tell me which IP netblock these queries are originating
from? I smell a previously unallocated (to an RIR) block which is in my
bogons list.
Thanks!
Graeme
^ permalink raw reply
* Re: serial-console: IMAGE_FEATURE, MACHINE_FEATURE or DISTRO_FEATURE?
From: Frans Meulenbroeks @ 2011-10-24 8:27 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <F930E711-421C-439B-AAA8-EEBA0371ED86@dominion.thruhere.net>
[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]
2011/10/24 Koen Kooi <koen@dominion.thruhere.net>
> Hi,
>
> Otavio is cleaning up systemd in meta-oe to work with his initramfs setup
> and we stumbled onto a challenge that we'd like some more feedback on.
>
> The old sysvinit recipes always hardcode a serial getty into inittab,
> systemd installs a getty@<port>.service file instead. Otavio doesn't need
> (or want) a getty on serial in his setup, but I need (and want) it on all my
> setups. So we agreed that it needs to be a feature :)
>
> I nitially suggested MACHINE_FEATURE, which Otavio implemented here:
> http://patchwork.openembedded.org/patch/13713/ , but I'm having second
> thoughs about it and am leaning toward an IMAGE_FEATURE instead. Since this
> involves *_FEATURE and we want systemd to move into oe-core eventually I'm
> moving the discussion from OE-devel to OE-core. Not much discussion has been
> going on, so I hope we'll get some more feedback here. I'll try to
> buttonhole some more OE developers at ELC and report back as well.
> <http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core>
Technically it is probably both.
I've seen embedded systems without a console. That seems to indicate a
machine feature.
Then again even if you have a console you might not want to enable it (e.g.
in order not to give the customer root access or even info wrt printk etc).
That seems to indicate a machine feature.
Probably the answer is inbetween: A machine feature HAS_CONSOLE or something
like that and an image feature CONSOLE_ENABLED.
My 2 cents.
Frans
[-- Attachment #2: Type: text/html, Size: 1973 bytes --]
^ permalink raw reply
* Re: [PATCH] staging:iio:treewide only use shared to decide on interfaces
From: Jonathan Cameron @ 2011-10-24 8:33 UTC (permalink / raw)
To: Lars-Peter Clausen; +Cc: linux-iio, michael.hennerich, device-drivers-devel
In-Reply-To: <4EA5220A.6010301@metafoo.de>
On 10/24/11 09:30, Lars-Peter Clausen wrote:
> On 10/21/2011 05:39 PM, Jonathan Cameron wrote:
>> Internally the fact that say scale is shared across channels is
>> actually of remarkably little interest. Hence lets not store it.
>> Numerous devices have weird combinations of channels sharing
>> scale anyway so it is not as though this was really telling
>> us much. Note however that we do still use the shared sysfs
>> attrs thus massively reducing the number of attrs in complex
>> drivers.
>>
>> Side effect is that certain drivers that were abusing this
>> (mostly my work) needed to do a few more checks on what the
>> channel they are being queried on actually is.
>>
>> This is also helpful for in kernel interfaces where we
>> just want to query the scale and don't care whether it
>> is shared with other channels or not.
>>
>> Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
>
> Hi
>
> Seems to work. I think it makes sense to submit this one and the other,
> which removes the bitmask addressing, together. Will you take care of this?
Yes. Might take a few days to hit though as I would guess Greg is going
to be busy at the kernel summit.
Are you happy to Ack this patch or if not give a tested-by.
Whilst I can push stuff on without review to Greg, I always prefer not to!
Jonathan
^ permalink raw reply
* Re: [PATCH] ceph: fix memory leak in async readpages
From: Jeff Wu @ 2011-10-24 8:28 UTC (permalink / raw)
To: Sage Weil; +Cc: David Flynn, ceph-devel@vger.kernel.org
In-Reply-To: <Pine.LNX.4.64.1109281215280.13650@cobra.newdream.net>
Hi ,
start_read() do twice "kfree(pages)",
................
out_pages:
ceph_release_page_vector(pages, nr_pages);
kfree(pages);
ceph_release_page_vector had kfree pages, continue to do kfree(pages),
sometimes ,async read ,printk "BUG kmalloc-16: Object already
free" ,then OOPS.
Jeff Wu
----------------------------------------------------------------------
void ceph_release_page_vector(struct page **pages, int num_pages)
{
int i;
for (i = 0; i < num_pages; i++)
__free_pages(pages[i], 0);
kfree(pages);
}
$ git diff
diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index 5ffee90..4144caf 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -345,7 +345,6 @@ static int start_read(struct inode *inode, struct
list_head *page_list, int max)
out_pages:
ceph_release_page_vector(pages, nr_pages);
- kfree(pages);
out:
ceph_osdc_put_request(req);
return ret;
On Thu, 2011-09-29 at 03:16 +0800, Sage Weil wrote:
> On Wed, 28 Sep 2011, Sage Weil wrote:
> > I'll send this upstream with the other patches so it'll hopefully make
> > 3.1...
>
> Er, not really.. this'll go upstream during the next merge window, along
> with the readahead code. :)
>
> sage
>
>
> >
> > Thanks!
> > sage
> >
> >
> > On Wed, 28 Sep 2011, David Flynn wrote:
> >
> > > The finish_read callback introduced in 63c90314546c1cec1f220f6ab24ea
> > > fails to release the page list allocated in start_read.
> > > ---
> > > fs/ceph/addr.c | 1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
> > > index e06a322..4144caf 100644
> > > --- a/fs/ceph/addr.c
> > > +++ b/fs/ceph/addr.c
> > > @@ -261,6 +261,7 @@ static void finish_read(struct ceph_osd_request *req, struct ceph_msg *msg)
> > > unlock_page(page);
> > > page_cache_release(page);
> > > }
> > > + kfree(req->r_pages);
> > > }
> > >
> > > /*
> > > --
> > > 1.7.4.1
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe ceph-devel" 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 ceph-devel" 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 ceph-devel" 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 related
* Re: [Xenomai-help] installing xenomai on pandaboard
From: Gilles Chanteperdrix @ 2011-10-24 8:33 UTC (permalink / raw)
To: Robert; +Cc: xenomai
In-Reply-To: <2b889a6c.722ea076.4ea51970.edef6@domain.hid>
On 10/24/2011 09:53 AM, Robert wrote:
>
>
>
> Dnia 20 września 2011 20:13 Gilles Chanteperdrix <gilles.chanteperdrix@domain.hid> napisał(a):
>
>> On 09/20/2011 07:26 PM, Robert wrote:
>>> Can someone help me installing xenomai on panda?
>>>
>>> What should I do, to install xenomai on ubuntu host?
>>> Download kernel from kernel.org and patch it with xenomai and adeos-patch, or download kernel from git repository, or download ubuntu image-omap4 via apt-get source?
>>>
>>> The last one would download 2.6.38 kernel, but there is no adeos patch for this version yet.
>>> It is also possible to download 2.6.37-9, but the same problem.
>>
>> The upcoming xenomai 2.6.0 supports panda. It should be released real
>> soon now, in the mean-time, you can try xenomai 2.6.0-rc3.
>>
>>
>
> Hi again,
> I have downloaded xenomai 2.6.0-rc5, and kernel 2.6.38.8 from kernel.org to ubuntu 11.04 on pandaboard.
> Patched it with adeos included in xeno package.
>
> Compiled the kernel, modules and copied uImage to boot partition.
> After reboot i got the following dmesg | grep -i xeno:
> user@domain.hid$ dmesg | grep -i xeno
> [ 1.195556] I-pipe: Domain Xenomai registered.
> [ 1.195587] Xenomai: hal/arm started.
> [ 1.195861] Xenomai: scheduling class idle registered.
> [ 1.195861] Xenomai: scheduling class rt registered.
> [ 1.199798] Xenomai: real-time nucleus v2.6.0-rc5 (head) loaded.
> [ 1.199798] Xenomai: debug mode enabled.
> [ 1.590240] Xenomai: native skin init failed, code -19.
> [ 1.590270] Xenomai: starting POSIX services.
> [ 1.980804] Xenomai: POSIX skin init failed, code -19.
> [ 2.371429] Xenomai: RTDM skin init failed, code -19.
>
> user@domain.hid$ modprobe -l | grep -i xeno
> user@domain.hid$ modprobe xeno_native
> user@domain.hid$ modprobe -l | grep -i xeno
>
> user@domain.hid$ sudo ./xeno-test
> /usr/xenomai/bin/xeno-test-run-wrapper: 19: source: not found
> ./xeno-test failed: dead child 1238 not found!
That is surprising, what shell do you use? Have you copied all files
installed by xenomai on the board root filesystem?
>
> user@domain.hid$ ./cond-torture-native
> Xenomai: incompatible feature set
> (userland requires "kuser_tsc fastsynch nosmp", kernel provides "sa1100 v6 eabi
> kuser_tsc fastsynch smp", missing="nosmp").
>
> Should I disable smp in kernel config?
That, or more likely enable smp in user-space configuration.
--
Gilles.
^ permalink raw reply
* [U-Boot] [PATCH] qong: remove unneeded "1" from qong.h
From: Stefano Babic @ 2011-10-24 8:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319216634-2754-1-git-send-email-fabio.estevam@freescale.com>
On 10/21/2011 07:03 PM, Fabio Estevam wrote:
> Remove unneeded "1" from qong.h.
Hi Fabio,
thanks for your "cleanup" work, it is high appreciated !
>
> /*
> * Filesystem
> @@ -311,6 +311,6 @@ extern int qong_nand_rdy(void *chip);
> #define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)
> #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET)
>
> -#define CONFIG_BOARD_EARLY_INIT_F 1
> +#define CONFIG_BOARD_EARLY_INIT_F
>
> #endif /* __CONFIG_H */
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: Vanilla-Kernel 3 - page allocation failure
From: Stefan Priebe - Profihost AG @ 2011-10-24 8:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: p.herz, David Rientjes, Andi Kleen, linux-kernel
In-Reply-To: <1319444998.2381.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Am 24.10.2011 10:29, schrieb Eric Dumazet:
> Le lundi 24 octobre 2011 à 10:19 +0200, Philipp Herz - Profihost AG a
> écrit :
>> Currently i can not provide any further information, 'cause server has
>> been restarted.
>>
>> What exactly are you looking for?
>
> A dmesg for 2.6.32 is OK, I look for :
>
> - memory layout (tg3 has workarounds for 4G crossing),
> - and exact tg3 chip, tg3 messages...
Here is a dmesg from 2.6.38 where this message also does not occur:
http://pastebin.com/raw.php?i=HjDEKVcp
Stefan
^ permalink raw reply
* Re: [Qemu-devel] Question about intermediate code generation in qemu (tcg)
From: Peter Maydell @ 2011-10-24 8:39 UTC (permalink / raw)
To: Carter Cheng; +Cc: qemu-devel
In-Reply-To: <CALS6=qVFDqhOuPCRMOOSLXsw5_EFZrGS1mt16FN3FJt7Ov9p=A@mail.gmail.com>
On 24 October 2011 07:46, Carter Cheng <cartercheng@gmail.com> wrote:
> I was wondering if someone could help me understand some aspects of the
> current qemu code generation routines. How are floating point and SSE ops
> currently handled? I do not see specific tcg routines for these cases(the
> README seems to indicate that FP and vector ops are not handled using the
> current IL).
FP instructions are generally turned into code which calls out to
a "helper function" written in C which emulates the floating point
arithmetic -- see target-i386/op_helper.c for the x87 ops and
target-i386/ops_sse.h for the SSE ops. (Some simple arithmetic
vector ops might be done by generating inline code; ARM does this
but I haven't checked target-i386.) IEEE arithmetic emulation
is done in fpu/ but you probably don't need to look at the actual
implementation...
In the TCG intermediate representation there's no special support
for float/double types -- they're just passed around as i32/i64.
-- PMM
^ permalink raw reply
* Re: [Xenomai-help] installing xenomai on pandaboard
From: Gilles Chanteperdrix @ 2011-10-24 8:41 UTC (permalink / raw)
To: Robert; +Cc: xenomai
In-Reply-To: <2b889a6c.722ea076.4ea51970.edef6@domain.hid>
On 10/24/2011 09:53 AM, Robert wrote:
> Compiled the kernel, modules and copied uImage to boot partition.
> After reboot i got the following dmesg | grep -i xeno:
> user@domain.hid$ dmesg | grep -i xeno
> [ 1.195556] I-pipe: Domain Xenomai registered.
> [ 1.195587] Xenomai: hal/arm started.
> [ 1.195861] Xenomai: scheduling class idle registered.
> [ 1.195861] Xenomai: scheduling class rt registered.
> [ 1.199798] Xenomai: real-time nucleus v2.6.0-rc5 (head) loaded.
> [ 1.199798] Xenomai: debug mode enabled.
> [ 1.590240] Xenomai: native skin init failed, code -19.
> [ 1.590270] Xenomai: starting POSIX services.
> [ 1.980804] Xenomai: POSIX skin init failed, code -19.
> [ 2.371429] Xenomai: RTDM skin init failed, code -19.
Missed that. Please post us your .config
--
Gilles.
^ permalink raw reply
* [RFC 0/4] simplify remapping a resource for drivers
From: Wolfram Sang @ 2011-10-24 8:42 UTC (permalink / raw)
To: linux-arm-kernel
Mostly all platform drivers need to do something like this to get a ioremapped
pointer from a resource (and some have multiple resources to be remapped):
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(&pdev->dev, "can't get device resources\n");
return -ENOENT;
}
res_size = resource_size(res);
if (!devm_request_mem_region(&pdev->dev, res->start, res_size, res->name)) {
dev_err(&pdev->dev, "can't allocate %d bytes at %d address\n",
res_size, res->start);
return -EBUSY;
}
priv->base = devm_ioremap_nocache(&pdev->dev, res->start, res_size);
if (priv->base) {
dev_err(&pdev->dev, "ioremap failed\n");
return -ENOMEM;
}
In case of not using managed devices, there is also code for cleaning up when
hitting an error. After this series, the same can be done with:
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
err = devm_resource_to_mapped_ptr(&pdev->dev, res, &priv->base);
if (err)
return err;
The new function will perform all necessary checks and return with consistent
error codes and messages on failures. It also prevents common mistakes like
using a wrong type for res_size or not calling the _nocache-variant of ioremap
if the resource is not marked otherwise. Because the new functions works with
the struct device (plus a resource), it will probably be useful even if
platform drivers run out of fashion.
The first two patches are minor cleanups on devres found while working on the code.
The third patch adds the new function. The fourth patch is an example, so we have a
simple use-case for the proposed functionality.
The series can also be fetched from:
git://git.pengutronix.de/git/wsa/linux-2.6.git resource_to_ptr
Looking forward to reviews and comments.
Thanks,
Wolfram
Wolfram Sang (4):
Documentation: devres: add allocation functions to list of supported calls
lib: devres: add annotations for #endif
lib: devres: add function which remaps a given resource
watchdog: imx2: simplify resource allocation
Documentation/driver-model/devres.txt | 5 +++
drivers/watchdog/imx2_wdt.c | 22 ++-----------
include/linux/device.h | 3 ++
lib/devres.c | 56 +++++++++++++++++++++++++++++++-
4 files changed, 65 insertions(+), 21 deletions(-)
--
1.7.6.3
^ permalink raw reply
* [RFC 0/4] simplify remapping a resource for drivers
From: Wolfram Sang @ 2011-10-24 8:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-kernel, Greg KH, Grant Likely, Tejun Heo, Wolfram Sang
Mostly all platform drivers need to do something like this to get a ioremapped
pointer from a resource (and some have multiple resources to be remapped):
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(&pdev->dev, "can't get device resources\n");
return -ENOENT;
}
res_size = resource_size(res);
if (!devm_request_mem_region(&pdev->dev, res->start, res_size, res->name)) {
dev_err(&pdev->dev, "can't allocate %d bytes at %d address\n",
res_size, res->start);
return -EBUSY;
}
priv->base = devm_ioremap_nocache(&pdev->dev, res->start, res_size);
if (priv->base) {
dev_err(&pdev->dev, "ioremap failed\n");
return -ENOMEM;
}
In case of not using managed devices, there is also code for cleaning up when
hitting an error. After this series, the same can be done with:
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
err = devm_resource_to_mapped_ptr(&pdev->dev, res, &priv->base);
if (err)
return err;
The new function will perform all necessary checks and return with consistent
error codes and messages on failures. It also prevents common mistakes like
using a wrong type for res_size or not calling the _nocache-variant of ioremap
if the resource is not marked otherwise. Because the new functions works with
the struct device (plus a resource), it will probably be useful even if
platform drivers run out of fashion.
The first two patches are minor cleanups on devres found while working on the code.
The third patch adds the new function. The fourth patch is an example, so we have a
simple use-case for the proposed functionality.
The series can also be fetched from:
git://git.pengutronix.de/git/wsa/linux-2.6.git resource_to_ptr
Looking forward to reviews and comments.
Thanks,
Wolfram
Wolfram Sang (4):
Documentation: devres: add allocation functions to list of supported calls
lib: devres: add annotations for #endif
lib: devres: add function which remaps a given resource
watchdog: imx2: simplify resource allocation
Documentation/driver-model/devres.txt | 5 +++
drivers/watchdog/imx2_wdt.c | 22 ++-----------
include/linux/device.h | 3 ++
lib/devres.c | 56 +++++++++++++++++++++++++++++++-
4 files changed, 65 insertions(+), 21 deletions(-)
--
1.7.6.3
^ permalink raw reply
* [RFC 4/4] watchdog: imx2: simplify resource allocation
From: Wolfram Sang @ 2011-10-24 8:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-kernel, Greg KH, Grant Likely, Tejun Heo, Wolfram Sang
In-Reply-To: <1319445729-14841-1-git-send-email-w.sang@pengutronix.de>
Use the new devm_resource_to_mapped_ptr function to simplify the code
and standardize the error-handling. Silently fixes a wrong type for the
resource_size variable as well.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
drivers/watchdog/imx2_wdt.c | 22 +++-------------------
1 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index b8ef2c6..1fc6714 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -247,28 +247,12 @@ static struct miscdevice imx2_wdt_miscdev = {
static int __init imx2_wdt_probe(struct platform_device *pdev)
{
int ret;
- int res_size;
struct resource *res;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "can't get device resources\n");
- return -ENODEV;
- }
-
- res_size = resource_size(res);
- if (!devm_request_mem_region(&pdev->dev, res->start, res_size,
- res->name)) {
- dev_err(&pdev->dev, "can't allocate %d bytes at %d address\n",
- res_size, res->start);
- return -ENOMEM;
- }
-
- imx2_wdt.base = devm_ioremap_nocache(&pdev->dev, res->start, res_size);
- if (!imx2_wdt.base) {
- dev_err(&pdev->dev, "ioremap failed\n");
- return -ENOMEM;
- }
+ ret = devm_resource_to_mapped_ptr(&pdev->dev, res, &imx2_wdt.base);
+ if (ret)
+ return ret;
imx2_wdt.clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(imx2_wdt.clk)) {
--
1.7.6.3
^ permalink raw reply related
* [RFC 3/4] lib: devres: add convenience function to remap a resource
From: Wolfram Sang @ 2011-10-24 8:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-kernel, Greg KH, Grant Likely, Tejun Heo, Wolfram Sang
In-Reply-To: <1319445729-14841-1-git-send-email-w.sang@pengutronix.de>
Almost every platform_driver does the three steps get_resource,
request_mem_region, ioremap. This does not only lead to a lot of code
duplication, but also a number of similar error strings and inconsistent
error codes on failure. So, introduce a helper function which simplifies
remapping a resource and make it hard to do something wrong.
A few notes on design choices:
* not 100% sure on ENOENT when the resource is invalid. Seems to be frequently
used currently and fits "somehow"
* the remapped pointer is a function argument and not a return value. This is to
save users from forgetting to use IS_ERR/PTR_ERR.
* the usage of IORESOURCE_CACHEABLE enforces calling the correct ioremap-variant.
A number of drivers miss to call the _nocache-version, although they should do.
* the new function is not named 'devm_ioremap_resource' because it does more than
just ioremap, namely request_mem_region. I didn't want to create implicit
knowledge here.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
Documentation/driver-model/devres.txt | 1 +
include/linux/device.h | 3 ++
lib/devres.c | 52 +++++++++++++++++++++++++++++++++
3 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index badd964..3aeb4f4 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -266,6 +266,7 @@ IOMAP
devm_ioremap()
devm_ioremap_nocache()
devm_iounmap()
+ devm_resource_to_mapped_ptr() : checks resource, requests region, ioremaps
pcim_iomap()
pcim_iounmap()
pcim_iomap_table() : array of mapped addresses indexed by BAR
diff --git a/include/linux/device.h b/include/linux/device.h
index c20dfbf..82a621c 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -481,6 +481,9 @@ extern int devres_release_group(struct device *dev, void *id);
extern void *devm_kzalloc(struct device *dev, size_t size, gfp_t gfp);
extern void devm_kfree(struct device *dev, void *p);
+int __must_check devm_resource_to_mapped_ptr(struct device *dev,
+ struct resource *res, void __iomem **dest);
+
struct device_dma_parameters {
/*
* a low level driver may set these to teach IOMMU code about
diff --git a/lib/devres.c b/lib/devres.c
index 78777ae..970588b 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -85,6 +85,58 @@ void devm_iounmap(struct device *dev, void __iomem *addr)
}
EXPORT_SYMBOL(devm_iounmap);
+/**
+ * devm_resource_to_mapped_ptr - Check, request region, and ioremap resource
+ * @dev: Generic device to handle the resource for
+ * @res: resource to be handled
+ * @dest: Pointer to pointer which carries the remapped address
+ *
+ * Takes all necessary steps to ioremap a mem resource. Uses managed device, so
+ * everything is undone on driver detach. Checks arguments, so you can feed
+ * it the result from e.g. platform_get_resource() directly:
+ *
+ * res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ * err = devm_resource_to_mapped_ptr(&pdev->dev, res, &priv->regs);
+ * if (err)
+ * return err;
+ */
+int __must_check devm_resource_to_mapped_ptr(struct device *dev,
+ struct resource *res, void __iomem **dest)
+{
+ resource_size_t size;
+ const char *name;
+
+ BUG_ON(!dev || !dest);
+
+ *dest = NULL;
+
+ if (!res || resource_type(res) != IORESOURCE_MEM) {
+ dev_err(dev, "invalid resource\n");
+ return -ENOENT;
+ }
+
+ size = resource_size(res);
+ name = res->name ?: dev_name(dev);
+
+ if (!devm_request_mem_region(dev, res->start, size, name)) {
+ dev_err(dev, "can't request region for resource %pR\n", res);
+ return -EBUSY;
+ }
+
+ if (res->flags & IORESOURCE_CACHEABLE)
+ *dest = devm_ioremap(dev, res->start, size);
+ else
+ *dest = devm_ioremap_nocache(dev, res->start, size);
+
+ if (!*dest) {
+ dev_err(dev, "ioremap failed for resource %pR\n", res);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(devm_resource_to_mapped_ptr);
+
#ifdef CONFIG_HAS_IOPORT
/*
* Generic iomap devres
--
1.7.6.3
^ permalink raw reply related
* [RFC 2/4] lib: devres: add annotations for #endif
From: Wolfram Sang @ 2011-10-24 8:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-kernel, Greg KH, Grant Likely, Tejun Heo, Wolfram Sang
In-Reply-To: <1319445729-14841-1-git-send-email-w.sang@pengutronix.de>
While working on devres, I found those make navigating the code a tad
easier.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
lib/devres.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/devres.c b/lib/devres.c
index 7c0e953..78777ae 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -348,5 +348,5 @@ void pcim_iounmap_regions(struct pci_dev *pdev, u16 mask)
}
}
EXPORT_SYMBOL(pcim_iounmap_regions);
-#endif
-#endif
+#endif /* CONFIG_PCI */
+#endif /* CONFIG_HAS_IOPORT */
--
1.7.6.3
^ permalink raw reply related
* [RFC 1/4] Documentation: devres: add allocation functions to list of supported calls
From: Wolfram Sang @ 2011-10-24 8:42 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-kernel, Greg KH, Grant Likely, Tejun Heo, Wolfram Sang
In-Reply-To: <1319445729-14841-1-git-send-email-w.sang@pengutronix.de>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
Documentation/driver-model/devres.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index d79aead..badd964 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -233,6 +233,10 @@ certainly invest a bit more effort into libata core layer).
6. List of managed interfaces
-----------------------------
+MEM
+ devm_kzalloc()
+ devm_kfree()
+
IO region
devm_request_region()
devm_request_mem_region()
--
1.7.6.3
^ permalink raw reply related
* [Qemu-devel] [PATCH] hw/9pfs: Make VirtTFS work correctly
From: Aneesh Kumar K.V @ 2011-10-24 8:44 UTC (permalink / raw)
To: qemu-devel; +Cc: aliguori, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
this patch fix multiple issues with VitFS tracing.
a) Add tracepoint to the correct code path. We handle error in complete_pdu
b) Fix indentation in python script
c) Fix variable naming issue in python script
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
hw/9pfs/virtio-9p.c | 60 +++++++-------
scripts/analyse-9p-simpletrace.py | 164 ++++++++++++++++++------------------
trace-events | 2 +-
3 files changed, 112 insertions(+), 114 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index aab3beb..8b6813f 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -969,7 +969,7 @@ static void complete_pdu(V9fsState *s, V9fsPDU *pdu, ssize_t len)
if (s->proto_version == V9FS_PROTO_2000L) {
id = P9_RLERROR;
}
- trace_complete_pdu(pdu->tag, pdu->id, err); /* Trace ERROR */
+ trace_v9fs_rerror(pdu->tag, pdu->id, err); /* Trace ERROR */
}
/* fill out the header */
@@ -1332,11 +1332,11 @@ static void v9fs_attach(void *opaque)
}
offset += pdu_marshal(pdu, offset, "Q", &qid);
err = offset;
+ trace_v9fs_attach_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_attach_return(pdu->tag, pdu->id,
- qid.type, qid.version, qid.path);
complete_pdu(s, pdu, err);
v9fs_string_free(&uname);
v9fs_string_free(&aname);
@@ -1371,13 +1371,12 @@ static void v9fs_stat(void *opaque)
}
offset += pdu_marshal(pdu, offset, "wS", 0, &v9stat);
err = offset;
+ trace_v9fs_stat_return(pdu->tag, pdu->id, v9stat.mode,
+ v9stat.atime, v9stat.mtime, v9stat.length);
v9fs_stat_free(&v9stat);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_stat_return(pdu->tag, pdu->id, v9stat.mode,
- v9stat.atime, v9stat.mtime, v9stat.length);
-
complete_pdu(s, pdu, err);
}
@@ -1421,13 +1420,12 @@ static void v9fs_getattr(void *opaque)
}
retval = offset;
retval += pdu_marshal(pdu, offset, "A", &v9stat_dotl);
-out:
- put_fid(pdu, fidp);
-out_nofid:
trace_v9fs_getattr_return(pdu->tag, pdu->id, v9stat_dotl.st_result_mask,
v9stat_dotl.st_mode, v9stat_dotl.st_uid,
v9stat_dotl.st_gid);
-
+out:
+ put_fid(pdu, fidp);
+out_nofid:
complete_pdu(s, pdu, retval);
}
@@ -1605,6 +1603,7 @@ static void v9fs_walk(void *opaque)
v9fs_path_copy(&newfidp->path, &path);
}
err = v9fs_walk_marshal(pdu, nwnames, qids);
+ trace_v9fs_walk_return(pdu->tag, pdu->id, nwnames, qids);
out:
put_fid(pdu, fidp);
if (newfidp) {
@@ -1613,7 +1612,6 @@ out:
v9fs_path_free(&dpath);
v9fs_path_free(&path);
out_nofid:
- trace_v9fs_walk_return(pdu->tag, pdu->id, nwnames, qids);
complete_pdu(s, pdu, err);
if (nwnames && nwnames <= P9_MAXWELEM) {
for (name_idx = 0; name_idx < nwnames; name_idx++) {
@@ -1648,10 +1646,10 @@ static int32_t get_iounit(V9fsPDU *pdu, V9fsPath *path)
static void v9fs_open(void *opaque)
{
int flags;
- int iounit;
int32_t fid;
int32_t mode;
V9fsQID qid;
+ int iounit = 0;
ssize_t err = 0;
size_t offset = 7;
struct stat stbuf;
@@ -1709,11 +1707,11 @@ static void v9fs_open(void *opaque)
offset += pdu_marshal(pdu, offset, "Qd", &qid, iounit);
err = offset;
}
+ trace_v9fs_open_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path, iounit);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_open_return(pdu->tag, pdu->id,
- qid.type, qid.version, qid.path, iounit);
complete_pdu(s, pdu, err);
}
@@ -1759,11 +1757,11 @@ static void v9fs_lcreate(void *opaque)
stat_to_qid(&stbuf, &qid);
offset += pdu_marshal(pdu, offset, "Qd", &qid, iounit);
err = offset;
+ trace_v9fs_lcreate_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path, iounit);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_lcreate_return(pdu->tag, pdu->id,
- qid.type, qid.version, qid.path, iounit);
complete_pdu(pdu->s, pdu, err);
v9fs_string_free(&name);
}
@@ -1978,10 +1976,10 @@ static void v9fs_read(void *opaque)
} else {
err = -EINVAL;
}
+ trace_v9fs_read_return(pdu->tag, pdu->id, count, err);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_read_return(pdu->tag, pdu->id, count, err);
complete_pdu(s, pdu, err);
}
@@ -2090,10 +2088,10 @@ static void v9fs_readdir(void *opaque)
retval = offset;
retval += pdu_marshal(pdu, offset, "d", count);
retval += count;
+ trace_v9fs_readdir_return(pdu->tag, pdu->id, count, retval);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_readdir_return(pdu->tag, pdu->id, count, retval);
complete_pdu(s, pdu, retval);
}
@@ -2202,10 +2200,10 @@ static void v9fs_write(void *opaque)
} while (total < count && len > 0);
offset += pdu_marshal(pdu, offset, "d", total);
err = offset;
+ trace_v9fs_write_return(pdu->tag, pdu->id, total, err);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_write_return(pdu->tag, pdu->id, total, err);
complete_pdu(s, pdu, err);
}
@@ -2362,11 +2360,11 @@ static void v9fs_create(void *opaque)
stat_to_qid(&stbuf, &qid);
offset += pdu_marshal(pdu, offset, "Qd", &qid, iounit);
err = offset;
+ trace_v9fs_create_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path, iounit);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_create_return(pdu->tag, pdu->id,
- qid.type, qid.version, qid.path, iounit);
complete_pdu(pdu->s, pdu, err);
v9fs_string_free(&name);
v9fs_string_free(&extension);
@@ -2401,11 +2399,11 @@ static void v9fs_symlink(void *opaque)
stat_to_qid(&stbuf, &qid);
offset += pdu_marshal(pdu, offset, "Q", &qid);
err = offset;
+ trace_v9fs_symlink_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path);
out:
put_fid(pdu, dfidp);
out_nofid:
- trace_v9fs_symlink_return(pdu->tag, pdu->id,
- qid.type, qid.version, qid.path);
complete_pdu(pdu->s, pdu, err);
v9fs_string_free(&name);
v9fs_string_free(&symname);
@@ -2950,10 +2948,11 @@ static void v9fs_mknod(void *opaque)
stat_to_qid(&stbuf, &qid);
err = offset;
err += pdu_marshal(pdu, offset, "Q", &qid);
+ trace_v9fs_mknod_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_mknod_return(pdu->tag, pdu->id, qid.type, qid.version, qid.path);
complete_pdu(s, pdu, err);
v9fs_string_free(&name);
}
@@ -3049,12 +3048,11 @@ static void v9fs_getlock(void *opaque)
glock->start, glock->length, glock->proc_id,
&glock->client_id);
err = offset;
+ trace_v9fs_getlock_return(pdu->tag, pdu->id, glock->type, glock->start,
+ glock->length, glock->proc_id);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_getlock_return(pdu->tag, pdu->id, glock->type, glock->start,
- glock->length, glock->proc_id);
-
complete_pdu(s, pdu, err);
v9fs_string_free(&glock->client_id);
g_free(glock);
@@ -3089,11 +3087,11 @@ static void v9fs_mkdir(void *opaque)
stat_to_qid(&stbuf, &qid);
offset += pdu_marshal(pdu, offset, "Q", &qid);
err = offset;
+ trace_v9fs_mkdir_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path, err);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_mkdir_return(pdu->tag, pdu->id,
- qid.type, qid.version, qid.path, err);
complete_pdu(pdu->s, pdu, err);
v9fs_string_free(&name);
}
@@ -3183,13 +3181,13 @@ static void v9fs_xattrwalk(void *opaque)
offset += pdu_marshal(pdu, offset, "q", size);
err = offset;
}
+ trace_v9fs_xattrwalk_return(pdu->tag, pdu->id, size);
out:
put_fid(pdu, file_fidp);
if (xattr_fidp) {
put_fid(pdu, xattr_fidp);
}
out_nofid:
- trace_v9fs_xattrwalk_return(pdu->tag, pdu->id, size);
complete_pdu(s, pdu, err);
v9fs_string_free(&name);
}
@@ -3260,11 +3258,11 @@ static void v9fs_readlink(void *opaque)
}
offset += pdu_marshal(pdu, offset, "s", &target);
err = offset;
+ trace_v9fs_readlink_return(pdu->tag, pdu->id, target.data);
v9fs_string_free(&target);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_readlink_return(pdu->tag, pdu->id, target.data);
complete_pdu(pdu->s, pdu, err);
}
diff --git a/scripts/analyse-9p-simpletrace.py b/scripts/analyse-9p-simpletrace.py
index 4358d6b..b6d58fd 100755
--- a/scripts/analyse-9p-simpletrace.py
+++ b/scripts/analyse-9p-simpletrace.py
@@ -7,11 +7,11 @@
import simpletrace
class VirtFSRequestTracker(simpletrace.Analyzer):
- def begin(self):
- print "Pretty printing 9p simpletrace log ..."
+ def begin(self):
+ print "Pretty printing 9p simpletrace log ..."
- def complete_pdu(self, tag, id, err):
- print "ERROR (tag =", tag, ", id =", id, ",err =", err, ")"
+ def v9fs_rerror(self, tag, id, err):
+ print "RERROR (tag =", tag, ", id =", id, ",err =", err, ")"
def v9fs_version(self, tag, id, msize, version):
print "TVERSION (tag =", tag, ", msize =", msize, ", version =", version, ")"
@@ -22,121 +22,121 @@ class VirtFSRequestTracker(simpletrace.Analyzer):
def v9fs_attach(self, tag, id, fid, afid, uname, aname):
print "TATTACH (tag =", tag, ", fid =", fid, ", afid =", afid, ", uname =", uname, ", aname =", aname, ")"
- def v9fs_attach_return(self, tag, id, type, verison, path):
- print "RATTACH (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "})"
+ def v9fs_attach_return(self, tag, id, type, version, path):
+ print "RATTACH (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "})"
- def v9fs_stat(self, tag, id, fid):
- print "TSTAT (tag =", tag, ", fid =", fid, ")"
+ def v9fs_stat(self, tag, id, fid):
+ print "TSTAT (tag =", tag, ", fid =", fid, ")"
- def v9fs_stat_return(self, tag, id, mode, atime, mtime, length):
- print "RSTAT (tag =", tag, ", mode =", mode, ", atime =", atime, ", mtime =", mtime, ", length =", length, ")"
+ def v9fs_stat_return(self, tag, id, mode, atime, mtime, length):
+ print "RSTAT (tag =", tag, ", mode =", mode, ", atime =", atime, ", mtime =", mtime, ", length =", length, ")"
- def v9fs_getattr(self, tag, id, fid, request_mask):
- print "TGETATTR (tag =", tag, ", fid =", fid, ", request_mask =", hex(request_mask), ")"
+ def v9fs_getattr(self, tag, id, fid, request_mask):
+ print "TGETATTR (tag =", tag, ", fid =", fid, ", request_mask =", hex(request_mask), ")"
- def v9fs_getattr_return(self, tag, id, result_mask, mode, uid, gid):
- print "RGETATTR (tag =", tag, ", result_mask =", hex(result_mask), ", mode =", oct(mode), ", uid =", uid, ", gid =", gid, ")"
+ def v9fs_getattr_return(self, tag, id, result_mask, mode, uid, gid):
+ print "RGETATTR (tag =", tag, ", result_mask =", hex(result_mask), ", mode =", oct(mode), ", uid =", uid, ", gid =", gid, ")"
- def v9fs_walk(self, tag, id, fid, newfid, nwnames):
- print "TWALK (tag =", tag, ", fid =", fid, ", newfid =", newfid, ", nwnames =", nwnames, ")"
+ def v9fs_walk(self, tag, id, fid, newfid, nwnames):
+ print "TWALK (tag =", tag, ", fid =", fid, ", newfid =", newfid, ", nwnames =", nwnames, ")"
- def v9fs_walk_return(self, tag, id, nwnames, qids):
- print "RWALK (tag =", tag, ", nwnames =", nwnames, ", qids =", hex(qids), ")"
+ def v9fs_walk_return(self, tag, id, nwnames, qids):
+ print "RWALK (tag =", tag, ", nwnames =", nwnames, ", qids =", hex(qids), ")"
- def v9fs_open(self, tag, id, fid, mode):
- print "TOPEN (tag =", tag, ", fid =", fid, ", mode =", oct(mode), ")"
+ def v9fs_open(self, tag, id, fid, mode):
+ print "TOPEN (tag =", tag, ", fid =", fid, ", mode =", oct(mode), ")"
- def v9fs_open_return(self, tag, id, type, version, path, iounit):
- print "ROPEN (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, iounit =", iounit, ")"
+ def v9fs_open_return(self, tag, id, type, version, path, iounit):
+ print "ROPEN (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, iounit =", iounit, ")"
- def v9fs_lcreate(self, tag, id, dfid, flags, mode, gid):
- print "TLCREATE (tag =", tag, ", dfid =", dfid, ", flags =", oct(flags), ", mode =", oct(mode), ", gid =", gid, ")"
+ def v9fs_lcreate(self, tag, id, dfid, flags, mode, gid):
+ print "TLCREATE (tag =", tag, ", dfid =", dfid, ", flags =", oct(flags), ", mode =", oct(mode), ", gid =", gid, ")"
- def v9fs_lcreate_return(self, id, type, version, path, iounit):
- print "RLCREATE (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, iounit =", iounit, ")"
+ def v9fs_lcreate_return(self, tag, id, type, version, path, iounit):
+ print "RLCREATE (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, iounit =", iounit, ")"
- def v9fs_fsync(self, tag, id, fid, datasync):
- print "TFSYNC (tag =", tag, ", fid =", fid, ", datasync =", datasync, ")"
+ def v9fs_fsync(self, tag, id, fid, datasync):
+ print "TFSYNC (tag =", tag, ", fid =", fid, ", datasync =", datasync, ")"
- def v9fs_clunk(self, tag, id, fid):
- print "TCLUNK (tag =", tag, ", fid =", fid, ")"
+ def v9fs_clunk(self, tag, id, fid):
+ print "TCLUNK (tag =", tag, ", fid =", fid, ")"
- def v9fs_read(self, tag, id, fid, off, max_count):
- print "TREAD (tag =", tag, ", fid =", fid, ", off =", off, ", max_count =", max_count, ")"
+ def v9fs_read(self, tag, id, fid, off, max_count):
+ print "TREAD (tag =", tag, ", fid =", fid, ", off =", off, ", max_count =", max_count, ")"
- def v9fs_read_return(self, tag, id, count, err):
- print "RREAD (tag =", tag, ", count =", count, ", err =", err, ")"
+ def v9fs_read_return(self, tag, id, count, err):
+ print "RREAD (tag =", tag, ", count =", count, ", err =", err, ")"
- def v9fs_readdir(self, tag, id, fid, offset, max_count):
- print "TREADDIR (tag =", tag, ", fid =", fid, ", offset =", offset, ", max_count =", max_count, ")"
+ def v9fs_readdir(self, tag, id, fid, offset, max_count):
+ print "TREADDIR (tag =", tag, ", fid =", fid, ", offset =", offset, ", max_count =", max_count, ")"
- def v9fs_readdir_return(self, tag, id, count, retval):
- print "RREADDIR (tag =", tag, ", count =", count, ", retval =", retval, ")"
+ def v9fs_readdir_return(self, tag, id, count, retval):
+ print "RREADDIR (tag =", tag, ", count =", count, ", retval =", retval, ")"
- def v9fs_write(self, tag, id, fid, off, count, cnt):
- print "TWRITE (tag =", tag, ", fid =", fid, ", off =", off, ", count =", count, ", cnt =", cnt, ")"
+ def v9fs_write(self, tag, id, fid, off, count, cnt):
+ print "TWRITE (tag =", tag, ", fid =", fid, ", off =", off, ", count =", count, ", cnt =", cnt, ")"
- def v9fs_write_return(self, tag, id, total, err):
- print "RWRITE (tag =", tag, ", total =", total, ", err =", err, ")"
+ def v9fs_write_return(self, tag, id, total, err):
+ print "RWRITE (tag =", tag, ", total =", total, ", err =", err, ")"
- def v9fs_create(self, tag, id, fid, perm, name, mode):
- print "TCREATE (tag =", tag, ", fid =", fid, ", perm =", oct(perm), ", name =", name, ", mode =", oct(mode), ")"
+ def v9fs_create(self, tag, id, fid, name, perm, mode):
+ print "TCREATE (tag =", tag, ", fid =", fid, ", perm =", oct(perm), ", name =", name, ", mode =", oct(mode), ")"
- def v9fs_create_return(self, tag, id, type, verison, path, iounit):
- print "RCREATE (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, iounit =", iounit, ")"
+ def v9fs_create_return(self, tag, id, type, version, path, iounit):
+ print "RCREATE (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, iounit =", iounit, ")"
- def v9fs_symlink(self, tag, id, fid, name, symname, gid):
- print "TSYMLINK (tag =", tag, ", fid =", fid, ", name =", name, ", symname =", symname, ", gid =", gid, ")"
+ def v9fs_symlink(self, tag, id, fid, name, symname, gid):
+ print "TSYMLINK (tag =", tag, ", fid =", fid, ", name =", name, ", symname =", symname, ", gid =", gid, ")"
- def v9fs_symlink_return(self, tag, id, type, version, path):
- print "RSYMLINK (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "})"
+ def v9fs_symlink_return(self, tag, id, type, version, path):
+ print "RSYMLINK (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "})"
- def v9fs_flush(self, tag, id, flush_tag):
- print "TFLUSH (tag =", tag, ", flush_tag =", flush_tag, ")"
+ def v9fs_flush(self, tag, id, flush_tag):
+ print "TFLUSH (tag =", tag, ", flush_tag =", flush_tag, ")"
- def v9fs_link(self, tag, id, dfid, oldfid, name):
- print "TLINK (tag =", tag, ", dfid =", dfid, ", oldfid =", oldfid, ", name =", name, ")"
+ def v9fs_link(self, tag, id, dfid, oldfid, name):
+ print "TLINK (tag =", tag, ", dfid =", dfid, ", oldfid =", oldfid, ", name =", name, ")"
- def v9fs_remove(self, tag, id, fid):
- print "TREMOVE (tag =", tag, ", fid =", fid, ")"
+ def v9fs_remove(self, tag, id, fid):
+ print "TREMOVE (tag =", tag, ", fid =", fid, ")"
- def v9fs_wstat(self, tag, id, fid, mode, atime, mtime):
- print "TWSTAT (tag =", tag, ", fid =", fid, ", mode =", oct(mode), ", atime =", atime, "mtime =", mtime, ")"
+ def v9fs_wstat(self, tag, id, fid, mode, atime, mtime):
+ print "TWSTAT (tag =", tag, ", fid =", fid, ", mode =", oct(mode), ", atime =", atime, "mtime =", mtime, ")"
- def v9fs_mknod(self, tag, id, fid, mode, major, minor):
- print "TMKNOD (tag =", tag, ", fid =", fid, ", mode =", oct(mode), ", major =", major, ", minor =", minor, ")"
+ def v9fs_mknod(self, tag, id, fid, mode, major, minor):
+ print "TMKNOD (tag =", tag, ", fid =", fid, ", mode =", oct(mode), ", major =", major, ", minor =", minor, ")"
- def v9fs_lock(self, tag, id, fid, type, start, length):
- print "TLOCK (tag =", tag, ", fid =", fid, "type =", type, ", start =", start, ", length =", length, ")"
+ def v9fs_lock(self, tag, id, fid, type, start, length):
+ print "TLOCK (tag =", tag, ", fid =", fid, "type =", type, ", start =", start, ", length =", length, ")"
- def v9fs_lock_return(self, tag, id, status):
- print "RLOCK (tag =", tag, ", status =", status, ")"
+ def v9fs_lock_return(self, tag, id, status):
+ print "RLOCK (tag =", tag, ", status =", status, ")"
- def v9fs_getlock(self, tag, id, fid, type, start, length):
- print "TGETLOCK (tag =", tag, ", fid =", fid, "type =", type, ", start =", start, ", length =", length, ")"
+ def v9fs_getlock(self, tag, id, fid, type, start, length):
+ print "TGETLOCK (tag =", tag, ", fid =", fid, "type =", type, ", start =", start, ", length =", length, ")"
- def v9fs_getlock_return(self, tag, id, type, start, length, proc_id):
- print "RGETLOCK (tag =", tag, "type =", type, ", start =", start, ", length =", length, ", proc_id =", proc_id, ")"
+ def v9fs_getlock_return(self, tag, id, type, start, length, proc_id):
+ print "RGETLOCK (tag =", tag, "type =", type, ", start =", start, ", length =", length, ", proc_id =", proc_id, ")"
- def v9fs_mkdir(self, tag, id, fid, name, mode, gid):
- print "TMKDIR (tag =", tag, ", fid =", fid, ", name =", name, ", mode =", mode, ", gid =", gid, ")"
+ def v9fs_mkdir(self, tag, id, fid, name, mode, gid):
+ print "TMKDIR (tag =", tag, ", fid =", fid, ", name =", name, ", mode =", mode, ", gid =", gid, ")"
- def v9fs_mkdir_return(self, tag, id, type, version, path, err):
- print "RMKDIR (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, err =", err, ")"
+ def v9fs_mkdir_return(self, tag, id, type, version, path, err):
+ print "RMKDIR (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, err =", err, ")"
- def v9fs_xattrwalk(self, tag, id, fid, newfid, name):
- print "TXATTRWALK (tag =", tag, ", fid =", fid, ", newfid =", newfid, ", xattr name =", name, ")"
+ def v9fs_xattrwalk(self, tag, id, fid, newfid, name):
+ print "TXATTRWALK (tag =", tag, ", fid =", fid, ", newfid =", newfid, ", xattr name =", name, ")"
- def v9fs_xattrwalk_return(self, tag, id, size):
- print "RXATTRWALK (tag =", tag, ", xattrsize =", size, ")"
+ def v9fs_xattrwalk_return(self, tag, id, size):
+ print "RXATTRWALK (tag =", tag, ", xattrsize =", size, ")"
- def v9fs_xattrcreate(self, tag, id, fid, name, size, flags):
- print "TXATTRCREATE (tag =", tag, ", fid =", fid, ", name =", name, ", xattrsize =", size, ", flags =", flags, ")"
+ def v9fs_xattrcreate(self, tag, id, fid, name, size, flags):
+ print "TXATTRCREATE (tag =", tag, ", fid =", fid, ", name =", name, ", xattrsize =", size, ", flags =", flags, ")"
- def v9fs_readlink(self, tag, id, fid):
- print "TREADLINK (tag =", tag, ", fid =", fid, ")"
+ def v9fs_readlink(self, tag, id, fid):
+ print "TREADLINK (tag =", tag, ", fid =", fid, ")"
- def v9fs_readlink_return(self, tag, id, target):
- print "RREADLINK (tag =", tag, ", target =", target, ")"
+ def v9fs_readlink_return(self, tag, id, target):
+ print "RREADLINK (tag =", tag, ", target =", target, ")"
simpletrace.run(VirtFSRequestTracker())
diff --git a/trace-events b/trace-events
index 7f9cec4..0f0a6b0 100644
--- a/trace-events
+++ b/trace-events
@@ -554,7 +554,7 @@ open_eth_desc_read(uint32_t addr, uint32_t v) "DESC[%04x] -> %08x"
open_eth_desc_write(uint32_t addr, uint32_t v) "DESC[%04x] <- %08x"
# hw/9pfs/virtio-9p.c
-complete_pdu(uint16_t tag, uint8_t id, int err) "tag %d id %d err %d"
+v9fs_rerror(uint16_t tag, uint8_t id, int err) "tag %d id %d err %d"
v9fs_version(uint16_t tag, uint8_t id, int32_t msize, char* version) "tag %d id %d msize %d version %s"
v9fs_version_return(uint16_t tag, uint8_t id, int32_t msize, char* version) "tag %d id %d msize %d version %s"
v9fs_attach(uint16_t tag, uint8_t id, int32_t fid, int32_t afid, char* uname, char* aname) "tag %u id %u fid %d afid %d uname %s aname %s"
--
1.7.5.4
^ permalink raw reply related
* Re: lvs-users mailing list and archive dead?
From: Tomasz Chmielewski @ 2011-10-24 8:45 UTC (permalink / raw)
To: Graeme Fowler; +Cc: lvs-devel
In-Reply-To: <1319445137.12559.0.camel@localhost>
On 24.10.2011 10:32, Graeme Fowler wrote:
> On Sun, 2011-10-23 at 21:52 +0200, Tomasz Chmielewski wrote:
>> I'm not able to resolve names from it from a largish German hosting
>> provider, Hetzner.
>
> Can you please tell me which IP netblock these queries are originating
> from? I smell a previously unallocated (to an RIR) block which is in my
> bogons list.
I.e. 178.63.195.*, 178.63.11.*, 46.4.130.*, 46.4.96.124, 46.4.115.*,
176.9.54.*.
--
Tomasz Chmielewski
http://wpkg.org
^ permalink raw reply
* Re: [GIT PULL for v3.2] OMAP_VOUT: Few cleaups and feature addition
From: Laurent Pinchart @ 2011-10-24 8:46 UTC (permalink / raw)
To: Hiremath, Vaibhav; +Cc: linux-media@vger.kernel.org, mchehab@redhat.com
In-Reply-To: <19F8576C6E063C45BE387C64729E739406C1010164@dbde02.ent.ti.com>
Hi Vaibhav,
On Monday 24 October 2011 10:18:32 Hiremath, Vaibhav wrote:
> On Monday, October 24, 2011 12:53 PM Laurent Pinchart wrote:
> > On Saturday 22 October 2011 14:06:24 hvaibhav@ti.com wrote:
> > > Hi Mauro,
> > >
> > > The following changes since commit
> > >
> > > 35a912455ff5640dc410e91279b03e04045265b2: Mauro Carvalho Chehab (1):
> > > Merge branch 'v4l_for_linus' into staging/for_v3.2
> > >
> > > are available in the git repository at:
> > > git://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git
> > >
> > > for-linux-media
> > >
> > > Archit Taneja (5):
> > > OMAP_VOUT: Fix check in reqbuf for buf_size allocation
> > > OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
> > > OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
> > > OMAP_VOUT: Add support for DSI panels
> > > OMAP_VOUT: Increase MAX_DISPLAYS to a larger value
> >
> > What about http://patchwork.linuxtv.org/patch/299/ ? Do you plan to push
> > it
> > through your tree, or should I push it through mine ?
>
> Oops,
>
> Missed it... Thanks for reminding me.
No worries.
> If you are about to send pull request then go ahead and merge it with your
> patch-sets. OR I can also send another request for this patch alone.
I've got omap3-isp patches I'm about to send a pull request for, I'll add the
omap_vout patch to the set.
--
Regards,
Laurent Pinchart
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.