Re: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration
On Mon, Mar 20, 2017 at 09:05:25AM +, Russell King - ARM Linux wrote:
> On Mon, Mar 20, 2017 at 09:55:12AM +0100, Philippe De Muyter wrote:
> > Hi Russel,
> >
> > On Sun, Mar 19, 2017 at 10:49:08AM +, Russell King wrote:
> > > Add support for enumerating frame sizes and frame intervals from the
> > > first subdev via the V4L2 interfaces.
> > >
> > > Signed-off-by: Russell King
> > > ---
> > > drivers/staging/media/imx/imx-media-capture.c | 62
> > > +++
> > > 1 file changed, 62 insertions(+)
> > >
> > ...
> > > +static int capture_enum_frameintervals(struct file *file, void *fh,
> > > +struct v4l2_frmivalenum *fival)
> > > +{
> > > + struct capture_priv *priv = video_drvdata(file);
> > > + const struct imx_media_pixfmt *cc;
> > > + struct v4l2_subdev_frame_interval_enum fie = {
> > > + .index = fival->index,
> > > + .pad = priv->src_sd_pad,
> > > + .width = fival->width,
> > > + .height = fival->height,
> > > + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> > > + };
> > > + int ret;
> > > +
> > > + cc = imx_media_find_format(fival->pixel_format, CS_SEL_ANY, true);
> > > + if (!cc)
> > > + return -EINVAL;
> > > +
> > > + fie.code = cc->codes[0];
> > > +
> > > + ret = v4l2_subdev_call(priv->src_sd, pad, enum_frame_interval, NULL,
> > > &fie);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + fival->type = V4L2_FRMIVAL_TYPE_DISCRETE;
> > > + fival->discrete = fie.interval;
> >
> > For some parallel sensors (mine is a E2V ev76c560) "any" frame interval is
> > possible,
> > and hence type should be V4L2_FRMIVAL_TYPE_CONTINUOUS.
>
> For my sensor, any frame interval is also possible, but that isn't the
> point here.
>
> /dev/video* only talks to the CSI source pad, not it's sink pad. The
> sink pad gets configured with the sensor frame rate via the media
> controller API. /dev/video* itself has no control over the sensor
> frame rate.
>
> The media controller stuff completely changes the way the established
> /dev/video* functionality works - the ability to select arbitary frame
> sizes and frame rates supported by the ultimate sensor is gone. All
> that needs to be setup through the media controller pipeline, one
> subdev at a time.
>
So existing gstreamer applications using /dev/video* to control framerate,
and even gain and exposure won't work anymore :( ?
I had hoped to keep compatibility, with added robustness and functionality.
I seems like I'll stay with my NXP/Freescale old and imperfect kernel.
Best regards
Philippe
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
Re: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration
Hi Russel,
On Sun, Mar 19, 2017 at 10:49:08AM +, Russell King wrote:
> Add support for enumerating frame sizes and frame intervals from the
> first subdev via the V4L2 interfaces.
>
> Signed-off-by: Russell King
> ---
> drivers/staging/media/imx/imx-media-capture.c | 62
> +++
> 1 file changed, 62 insertions(+)
>
...
> +static int capture_enum_frameintervals(struct file *file, void *fh,
> +struct v4l2_frmivalenum *fival)
> +{
> + struct capture_priv *priv = video_drvdata(file);
> + const struct imx_media_pixfmt *cc;
> + struct v4l2_subdev_frame_interval_enum fie = {
> + .index = fival->index,
> + .pad = priv->src_sd_pad,
> + .width = fival->width,
> + .height = fival->height,
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> + int ret;
> +
> + cc = imx_media_find_format(fival->pixel_format, CS_SEL_ANY, true);
> + if (!cc)
> + return -EINVAL;
> +
> + fie.code = cc->codes[0];
> +
> + ret = v4l2_subdev_call(priv->src_sd, pad, enum_frame_interval, NULL,
> &fie);
> + if (ret)
> + return ret;
> +
> + fival->type = V4L2_FRMIVAL_TYPE_DISCRETE;
> + fival->discrete = fie.interval;
For some parallel sensors (mine is a E2V ev76c560) "any" frame interval is
possible,
and hence type should be V4L2_FRMIVAL_TYPE_CONTINUOUS.
see also https://www.spinics.net/lists/linux-media/msg98622.html,
https://patchwork.kernel.org/patch/9171201/ and
https://patchwork.kernel.org/patch/9171199/
Philippe
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
Re: media / v4l2-mc: wishlist for complex cameras (was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline)
On Thu, Mar 16, 2017 at 11:01:56AM +0100, Philipp Zabel wrote: > On Thu, 2017-03-16 at 10:47 +0100, Philippe De Muyter wrote: > > On Thu, Mar 16, 2017 at 10:26:00AM +0100, Philipp Zabel wrote: > > > On Wed, 2017-03-15 at 14:55 -0400, Nicolas Dufresne wrote: > > > > Le mercredi 15 mars 2017 à 11:50 +0100, Philippe De Muyter a écrit : > > > > > > I would say: camorama, xawtv3, zbar, google talk, skype. If it runs > > > > > > with those, it will likely run with any other application. > > > > > > > > > > > > > > > > I would like to add the 'v4l2src' plugin of gstreamer, and on the > > > > > imx6 its > > > > > > > > While it would be nice if somehow you would get v4l2src to work (in > > > > some legacy/emulation mode through libv4l2), > > > > > > v4l2src works just fine, provided the pipeline is configured manually in > > > advance via media-ctl. > > > > Including choosing the framerate ? Sorry, I have no time these days > > to test it myself. > > No, the framerate is set with media-ctl on the CSI output pad. To really > choose the framerate, the element would indeed need a deeper > understanding of the pipeline, as the resulting framerate depends on at > least the source v4l2_subdevice (sensor) framerate and the CSI frame > skipping. Count me in than as a supporter of Steve's "v4l2-mc: add a function to inherit controls from a pipeline" patch > > of the image buffers for further processing by other (not necessarily next > > in gstreamer pipeline, or for all frames) hardware-accelerated plugins likes > > the h.264 video encoder. As I am stuck with fsl/nxp kernel and driver on > > that > > matter, I don't know how the interfaces have evolved in current linux > > kernels. > > The physical address of the image buffers is hidden from userspace by > dma-buf objects, but those can be passed around to the next driver > without copying the image data. OK thanks Philippe
Re: media / v4l2-mc: wishlist for complex cameras (was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline)
On Thu, Mar 16, 2017 at 10:26:00AM +0100, Philipp Zabel wrote: > On Wed, 2017-03-15 at 14:55 -0400, Nicolas Dufresne wrote: > > Le mercredi 15 mars 2017 à 11:50 +0100, Philippe De Muyter a écrit : > > > > I would say: camorama, xawtv3, zbar, google talk, skype. If it runs > > > > with those, it will likely run with any other application. > > > > > > > > > > I would like to add the 'v4l2src' plugin of gstreamer, and on the > > > imx6 its > > > > While it would be nice if somehow you would get v4l2src to work (in > > some legacy/emulation mode through libv4l2), > > v4l2src works just fine, provided the pipeline is configured manually in > advance via media-ctl. Including choosing the framerate ? Sorry, I have no time these days to test it myself. And I cited imxv4l2videosrc for its ability to provide the physical address of the image buffers for further processing by other (not necessarily next in gstreamer pipeline, or for all frames) hardware-accelerated plugins likes the h.264 video encoder. As I am stuck with fsl/nxp kernel and driver on that matter, I don't know how the interfaces have evolved in current linux kernels. BR Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
Re: media / v4l2-mc: wishlist for complex cameras (was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline)
On Tue, Mar 14, 2017 at 09:54:31PM -0300, Mauro Carvalho Chehab wrote: > Em Tue, 14 Mar 2017 23:32:54 +0100 > Pavel Machek escreveu: > > > > > Well, I believe first question is: what applications would we want to > > run on complex devices? Will sending control from video to subdevs > > actually help? > > I would say: camorama, xawtv3, zbar, google talk, skype. If it runs > with those, it will likely run with any other application. > I would like to add the 'v4l2src' plugin of gstreamer, and on the imx6 its imx-specific counterpart 'imxv4l2videosrc' from the gstreamer-imx package at https://github.com/Freescale/gstreamer-imx, and 'v4l2-ctl'. Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
Re: [PATCH] m68k: Fix ndelay() macro
On Fri, Oct 28, 2016 at 05:12:28PM +0200, Boris Brezillon wrote: > The current ndelay() macro definition has an extra semi-colon at the > end of the line thus leading to a compilation error when ndelay is used > in a conditional block with curly braces like this one: without curly braces > > if (cond) > ndelay(t); > else > ... > Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
Re: [PATCH 08/10] m68k: Add
On Wed, May 25, 2016 at 03:34:55AM -0400, George Spelvin wrote: > This provides a multiply by constant GOLDEN_RATIO_32 = 0x61C88647 > for the original mc68000, which lacks a 32x32-bit multiply instruction. > > Addition chains found by Yevgen Voronenko's Hcub algorithm at > http://spiral.ece.cmu.edu/mcm/gen.html Shouldn't you put that reference in the comments of your archhash.h file ? Philippe
Re: [PATCH 08/10] m68k: Add
On Wed, May 25, 2016 at 05:14:35AM -0400, George Spelvin wrote:
>
> I did it the way I did above because it makes the gcc -S output very
> legible. Just like I put a space before the perands on m68k but a tab
> on h8300: that's what GCC does on those platforms.
>
> I started with the "\n\t" suffixes on each line like so much other
> kernel code, but then figured out the format above which is legible
> both in C source and compiler output.
OK thanks.
>
> >>asm("move.l %2,%0;" /* 0x0001 */
> >>"lsl.l #2,%0;" /* 0x0004 */
> >>"move.l %0,%1;"
> >>"lsl.l #7,%0;" /* 0x0200 */
> >>"add.l %2,%0;" /* 0x0201 */
> >>"add.l %0,%1;" /* 0x0205 */
> >>"add.l %0,%0;" /* 0x0402 */
> >>"add.l %0,%1;" /* 0x0607 */
> >>"lsl.l #5,%0" /* 0x8040 */
> >>/* 0x8647 */
>
> > Also, it took me some time to understand the hexadecimal constants
> > in the comments (and the last one predicts a future event :)).
>
>
> Can you recmmend a better way to comment this? My nose is so deep
> in the code it's hard for me to judge.
I second Andreas' suggestion.
Philippe
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
Re: [PATCH 08/10] m68k: Add
On Wed, May 25, 2016 at 03:34:55AM -0400, George Spelvin wrote:
> +static inline u32 __attribute_const__ __hash_32(u32 x)
> +{
> + u32 a, b;
> +
> + asm( "move.l %2,%0" /* 0x0001 */
> + "\n lsl.l #2,%0"/* 0x0004 */
> + "\n move.l %0,%1"
> + "\n lsl.l #7,%0"/* 0x0200 */
> + "\n add.l %2,%0"/* 0x0201 */
> + "\n add.l %0,%1"/* 0x0205 */
> + "\n add.l %0,%0"/* 0x0402 */
> + "\n add.l %0,%1"/* 0x0607 */
> + "\n lsl.l #5,%0"/* 0x8040 */
> + /* 0x8647 */
There is no standard way to write asm in the kernel, but I prefer
a simple semicolon after each insn
asm("move.l %2,%0;" /* 0x0001 */
"lsl.l #2,%0;" /* 0x0004 */
"move.l %0,%1;"
"lsl.l #7,%0;" /* 0x0200 */
"add.l %2,%0;" /* 0x0201 */
"add.l %0,%1;" /* 0x0205 */
"add.l %0,%0;" /* 0x0402 */
"add.l %0,%1;" /* 0x0607 */
"lsl.l #5,%0" /* 0x8040 */
/* 0x8647 */
Also, it took me some time to understand the hexadecimal constants
in the comments (and the last one predicts a future event :)).
> + : "=&d" (a), "=&r" (b)
> + : "g" (x));
> +
> + return ((u16)(x*0x61c8) << 16) + a + b;
> +}
Just my two cents
Philippe
[PATCH] [media] gpu: ipu-v3: csi: add support for 8 bpp grayscale sensors.
Signed-off-by: Philippe De Muyter Cc: Steve Longerbeam Cc: Boris BREZILLON Cc: Philipp Zabel Cc: Hans Verkuil --- drivers/gpu/ipu-v3/ipu-csi.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c index 752cdd2..0ab0e3a 100644 --- a/drivers/gpu/ipu-v3/ipu-csi.c +++ b/drivers/gpu/ipu-v3/ipu-csi.c @@ -271,6 +271,7 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config *cfg, u32 mbus_code) case MEDIA_BUS_FMT_SGBRG8_1X8: case MEDIA_BUS_FMT_SGRBG8_1X8: case MEDIA_BUS_FMT_SRGGB8_1X8: + case MEDIA_BUS_FMT_Y8_1X8: cfg->data_fmt = CSI_SENS_CONF_DATA_FMT_BAYER; cfg->mipi_dt = MIPI_DT_RAW8; cfg->data_width = IPU_CSI_DATA_WIDTH_8; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] rtc: add rtc-abx80x, a driver for the Abracon AB x80x i2c rtc
Hi Alexandre,
On Wed, Apr 01, 2015 at 04:52:23AM +0200, Alexandre Belloni wrote:
> From: Philippe De Muyter
>
> This is a basic driver for the ultra-low-power Abracon AB x80x series of RTC
> chips. It supports in particular, the supersets AB0805 and AB1805.
> It allows reading and writing the time, and enables the supercapacitor/
> battery charger.
>
> [a...@arndb.de: abx805 depends on i2c]
> Signed-off-by: Philippe De Muyter
> Cc: Alessandro Zummo
> Signed-off-by: Alexandre Belloni
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Andrew Morton
> ---
...
> +static int abx80x_rtc_read_time(struct device *dev, struct rtc_time *tm)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + unsigned char date[8];
> + int err;
> +
> + err = i2c_smbus_read_i2c_block_data(client, ABX8XX_REG_HTH,
> + sizeof(date), date);
> + if (err < 0) {
> + dev_err(&client->dev, "Unable to read date\n");
> + return -EIO;
> + }
> +
> + tm->tm_sec = bcd2bin(date[ABX8XX_REG_SC] & 0x7F);
> + tm->tm_min = bcd2bin(date[ABX8XX_REG_MN] & 0x7F);
> + tm->tm_hour = bcd2bin(date[ABX8XX_REG_HR] & 0x3F);
> + tm->tm_wday = date[ABX8XX_REG_WD] & 0x7;
> + tm->tm_mday = bcd2bin(date[ABX8XX_REG_DA] & 0x3F);
> + tm->tm_mon = bcd2bin(date[ABX8XX_REG_MO] & 0x1F) - 1;
> + tm->tm_year = bcd2bin(date[ABX8XX_REG_YR]) + 100;
Just a minor nit: I would rather not name the buffer 'date', but 'buf' like
in abx80x_rtc_set_time.
> +
> + err = rtc_valid_tm(tm);
> + if (err < 0)
> + dev_err(&client->dev, "retrieved date/time is not valid.\n");
> +
> + return err;
> +}
> +
> +static int abx80x_rtc_set_time(struct device *dev, struct rtc_time *tm)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + unsigned char buf[8];
> + int err;
> +
...
> +static const struct i2c_device_id abx80x_id[] = {
> + { "abx80x", ABX80X },
should become
{ "abx80x-rtc", ABX80X },
> + { "ab0801", AB0801 },
> + { "ab0803", AB0803 },
> + { "ab0804", AB0804 },
> + { "ab0805", AB0805 },
> + { "ab1801", AB1801 },
> + { "ab1803", AB1803 },
> + { "ab1804", AB1804 },
> + { "ab1805", AB1805 },
> + { }
and likewise
Best regards
Philippe
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] Documentation: bindings: add abracon,abx80x
Hi Alexandre, when I look into Documentation/devicetree/bindings/rtc, it seems that all rtc but a few (mainly old ones) have the "-rtc" suffix in the "compatible" property. Would it not be better to keep it here also, like what I had written ? Best regards Philippe On Wed, Apr 01, 2015 at 04:52:22AM +0200, Alexandre Belloni wrote: > Document the bindings for abracon,abx80x and related compatibles. > > Cc: devicetree-disc...@lists.ozlabs.org > Signed-off-by: Alexandre Belloni > --- > .../devicetree/bindings/rtc/abracon,abx80x.txt | 32 > ++ > 1 file changed, 32 insertions(+) > create mode 100644 Documentation/devicetree/bindings/rtc/abracon,abx80x.txt > > diff --git a/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt > b/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt > new file mode 100644 > index ..6f0d3b2cdd89 > --- /dev/null > +++ b/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt > @@ -0,0 +1,32 @@ > +Abracon ABX80X I2C ultra low power RTC/Alarm chip > + > +The Abracon ABX80X family consist of the ab0801, ab0803, ab0804, ab0805, > ab1801, > +ab1803, ab1804 and ab1805. The ab0805 is the superset of ab080x and the > ab1805 > +is the superset of ab180x. > + > +Required properties: > + > + - "compatible": should one of: > +"abracon,abx80x" > +"abracon,ab0801" > +"abracon,ab0803" > +"abracon,ab0804" > +"abracon,ab0805" > +"abracon,ab1801" > +"abracon,ab1803" > +"abracon,ab1804" > +"abracon,ab1805" > + Using "abracon,abx80x" will enable chip autodetection. > + - "reg": I2C bus address of the device > + > +Optional properties: > + > +The abx804 and abx805 have a trickle charger that is able to charge the > +connected battery or supercap. Both the following properties have to be > defined > +and valid to enable charging: > + > + - "abracon,tc-diode": should be "standard" (0.6V) or "schottky" (0.3V) > + - "abracon,tc-resistor": should be <0>, <3>, <6> or <11>. 0 disables the > output > + resistor, the other values are in ohm. > + > + > -- > 2.1.0 -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] rtc: add rtc-abx80x, a driver for the Abracon AB x80x i2c rtc
On Sat, Mar 14, 2015 at 07:09:11PM +0100, Alexandre Belloni wrote: > On 14/03/2015 at 13:44:41 +0100, Philippe De Muyter wrote : > > > + tm->tm_sec = bcd2bin(date[ABX8XX_REG_SC] & 0x7F); > > > + tm->tm_min = bcd2bin(date[ABX8XX_REG_MN] & 0x7F); > > > + tm->tm_hour = bcd2bin(date[ABX8XX_REG_HR] & 0x3F); > > > + tm->tm_wday = date[ABX8XX_REG_WD] & 0x7; > > > + tm->tm_mday = bcd2bin(date[ABX8XX_REG_DA] & 0x3F); > > > + tm->tm_mon = bcd2bin(date[ABX8XX_REG_MO] & 0x1F) - 1; > > > + tm->tm_year = bcd2bin(date[ABX8XX_REG_YR]); > > > + if (tm->tm_year < 70) > > > > Is that still useful for a driver written in 2015 ? > > > > I'd say that this is actually the only correct way to do it. Only dates > before 01/01/1970 00:00 are considered invalid. So, unless adding a > check like: > > if (tm->tm_year < 100) > return -EINVAL; > > in abx80x_rtc_set_time, setting and then reading a date before 2000 will > fail silently. I'm open to add that check. You are right. It is actually more a consistency problem between rtc drivers and thus a question for the rtc-subsytem maintainer. Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] rtc: add rtc-abx80x, a driver for the Abracon AB x80x i2c rtc
Hi Alexandre,
Thanks for the merge. I have however some comments. They are not meant
to be exhaustive.
Philippe
On Sat, Mar 14, 2015 at 11:05:46AM +0100, Alexandre Belloni wrote:
> From: Philippe De Muyter
>
> This is a basic driver for the ultra-low-power Abracon AB x80x series of RTC
> chips. It supports in particular, the supersets AB0805 and AB1805.
> It allows reading and writing the time, and enables the supercapacitor/
> battery charger.
>
> [a...@arndb.de: abx805 depends on i2c]
> Signed-off-by: Philippe De Muyter
> Cc: Alessandro Zummo
> Signed-off-by: Alexandre Belloni
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Andrew Morton
> ---
> drivers/rtc/Kconfig | 10 ++
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-abx80x.c | 325
> +++
> 3 files changed, 336 insertions(+)
> create mode 100644 drivers/rtc/rtc-abx80x.c
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index b5b5c3d485d6..89507c1858ec 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -164,6 +164,16 @@ config RTC_DRV_ABB5ZES3
> This driver can also be built as a module. If so, the module
> will be called rtc-ab-b5ze-s3.
>
> +config RTC_DRV_ABX80X
> + tristate "Abracon ABx80x"
> + help
> + If you say yes here you get support for Abracon AB080X and AB180X
> + families of ultra-low-power battery- and capacitor-backed real-time
> + clock chips.
> +
> + This driver can also be built as a module. If so, the module
> + will be called rtc-abx80x.
> +
> config RTC_DRV_AS3722
> tristate "ams AS3722 RTC driver"
> depends on MFD_AS3722
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 69c87062b098..7b20b0462cb6 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_RTC_DRV_88PM80X) += rtc-88pm80x.o
> obj-$(CONFIG_RTC_DRV_AB3100) += rtc-ab3100.o
> obj-$(CONFIG_RTC_DRV_AB8500) += rtc-ab8500.o
> obj-$(CONFIG_RTC_DRV_ABB5ZES3) += rtc-ab-b5ze-s3.o
> +obj-$(CONFIG_RTC_DRV_ABX80X) += rtc-abx80x.o
> obj-$(CONFIG_RTC_DRV_ARMADA38X) += rtc-armada38x.o
> obj-$(CONFIG_RTC_DRV_AS3722) += rtc-as3722.o
> obj-$(CONFIG_RTC_DRV_AT32AP700X)+= rtc-at32ap700x.o
> diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
> new file mode 100644
> index ..8424e500f1da
> --- /dev/null
> +++ b/drivers/rtc/rtc-abx80x.c
> @@ -0,0 +1,325 @@
> +/*
> + * A driver for the I2C members of the Abracon AB x8xx RTC family,
> + * and compatible: AB 1805 and AB 0805
> + *
> + * Copyright 2014-2015 Macq S.A.
> + *
> + * Author: Philippe De Muyter
> + * Author: Alexandre Belloni
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#define ABX8XX_REG_HTH 0x00
> +#define ABX8XX_REG_SC0x01
> +#define ABX8XX_REG_MN0x02
> +#define ABX8XX_REG_HR0x03
> +#define ABX8XX_REG_DA0x04
> +#define ABX8XX_REG_MO0x05
> +#define ABX8XX_REG_YR0x06
> +#define ABX8XX_REG_WD0x07
> +
> +#define ABX8XX_REG_CTRL1 0x10
> +#define ABX8XX_CTRL_WRITEBIT(1)
> +#define ABX8XX_CTRL_12_24BIT(6)
> +
> +#define ABX8XX_REG_CFG_KEY 0x1f
> +#define ABX8XX_CFG_KEY_MISC 0x9d
> +
> +#define ABX8XX_REG_ID0 0x28
> +
> +#define ABX8XX_REG_TRICKLE 0x20
> +#define ABX8XX_TRICKLE_CHARGE_ENABLE 0xa0
> +#define ABX8XX_TRICKLE_STANDARD_DIODE0x8
> +#define ABX8XX_TRICKLE_SCHOTTKY_DIODE0x4
> +
> +static u8 trickle_resistors[] = {0, 3, 6, 11};
> +
> +enum abx80x_chip {AB0801, AB0803, AB0804, AB0805,
> + AB1801, AB1803, AB1804, AB1805, ABX80X};
> +
> +struct abx80x_cap {
> + u16 pn;
> + bool has_tc;
> +};
> +
> +static struct abx80x_cap abx80x_caps[] = {
> + [AB0801] = {.pn = 0x0801},
> + [AB0803] = {.pn = 0x0803},
> + [AB0804] = {.pn = 0x0804, .has_tc = true},
> + [AB0805] = {.pn = 0x0805, .has_tc = true},
> + [AB1801] = {.pn = 0x1801},
> + [AB1803] = {.pn = 0x1803},
> + [AB1804] = {.pn = 0x1804, .has_tc = true},
> + [AB1805] = {.pn = 0x1805, .has_tc = true},
> + [ABX80X] = {.pn = 0}
> +};
> +
> +static struct i2c_driver abx80x_driver;
> +
> +static int abx80x_enable_trickle_charger(struct i2c_client *client,
> +
Re: [PATCH v2] rtc: add Abracon ABx80x driver
Hi Alexandre,
On Wed, Mar 04, 2015 at 11:38:14AM +0100, Alexandre Belloni wrote:
> On 04/03/2015 at 10:55:56 +0100, Philippe De Muyter wrote :
> > > The "AB08XX Real-Time Clock Family" document states that they are all
> > > software and pin compatible (including the AB18xx).
> >
> > Which part(s) do you really have ? Mine is a 1805. Do all the parts have
> > the trickle charger ? As I don't know, I prefer not to pretend that the
> > driver supports those chips.
> >
>
> I have the AB0805. The trickle charger is not available on ABx8x1 and
> ABx8x3.
>
> > > > My hardware colleagues told me that the only way to enable the 'ultra
> > > > low-power'
> > > > functionality is enabling the trickle charger. And the 'ultra
> > > > low-power'
> > > > functionality is the reason we choose that chip, so I would at least
> > > > keep that as the default behaviour.
> > > >
> > >
> > > My concern is that you have a static configuration. I would expose a
> > > sysfs interface to configure the diode, resistor and enable/disable the
> > > trickle charger. Would that work for you?
> >
> > I think a 'of_xxx' dts/dtb description is the way to go, but I did not want
> > to
> > introduce unnecessaty complexity without knowing other usages. My hardware
> > colleagues followed the recommended design from Abracon.
> >
>
> Yeah, I'm not sure about the DT description, some may argue this is
> configuration. But I guess it actually depends on the battery you are
> using so that could count as hardware description.
As far as I know, it's purely hardware related.
>
> I'll use:
> abracon,tc-diode = "(standard|schottky)"
> abracon,tc-resistor = <(0|3|6|11)>
>
> If both are defined and valid, I'll enable the trickle charger with the
> provided configuration in probe().
My current entry is :
&i2c2 {
...
ab1805@69 {
compatible = "abracon,abx805-rtc";
reg = <0x69>;
position = <3>;
};
};
It would then become :
&i2c2 {
...
ab1805@69 {
compatible = "abracon,abx805-rtc";
reg = <0x69>;
position = <3>;
abracon,tc-diode = "schottky";
abracon,tc-resistor = <3>;
};
};
or if you change the driver's name to "abx80x-rtc"
compatible = "abracon,abx80x-rtc";
That's fine for me. Thanks !
Philippe
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] rtc: add Abracon ABx80x driver
Hi Alexandre, On Wed, Mar 04, 2015 at 10:06:01AM +0100, Alexandre Belloni wrote: > On 04/03/2015 at 09:52:42 +0100, Philippe De Muyter wrote : > > > > And is the naming in Philippe's driver appropriate? If it supports the > > > > AB1801 (for example) then why is it described as an "abx805" driver? > > > > > > The real naming is in the form ABx8yz. With: > > > > > > x: 0 or 1, indicate the presence of the reset management > > > y: 0 or 1: 0 is i2c, 1 is spi > > > z: [1-5]: different amount of on chip SRAM. From what I understand, only > > > ABx8y5 are actually recommended for new designs. > > > > My driver is based on the datashet called 'AB18X5 Real-Time Clock with > > Power Management Family', which calls the parts 'AB18X5 family' with X > > being '0' for I2c parts and '1' for SPI parts. > > > > As the part I have and the driver I wrote are I2C, not SPI, I fixed the > > 'X' as 0 in the name of the driver. > > > > The datasheet lists only one part as being 'software and pin compatible' > > with the 'AB1805': the 'AB0805', hence the 'x' in the name I choose : > > abx805. > > > > The "AB08XX Real-Time Clock Family" document states that they are all > software and pin compatible (including the AB18xx). Which part(s) do you really have ? Mine is a 1805. Do all the parts have the trickle charger ? As I don't know, I prefer not to pretend that the driver supports those chips. > > > Actually, my driver is used in production and works fine, because the > > default(reset) value of the 12/24 mode bit is '24 hour mode' and the > > default value of the 'write RTC bit' enables writing. There is > > no real need to play with them. > > > > I know this is unlikely to happen but what if someone messes with the > RTC in the bootloader? Yes, you may unconditionnaly rewrite this register if you want. > > > > > > > What I like in Philippe's driver is the info printed at probe time and > > > the support for trickle charging. However, I wouldn't enable it > > > unconditionally. > > > > My hardware colleagues told me that the only way to enable the 'ultra > > low-power' > > functionality is enabling the trickle charger. And the 'ultra low-power' > > functionality is the reason we choose that chip, so I would at least > > keep that as the default behaviour. > > > > My concern is that you have a static configuration. I would expose a > sysfs interface to configure the diode, resistor and enable/disable the > trickle charger. Would that work for you? I think a 'of_xxx' dts/dtb description is the way to go, but I did not want to introduce unnecessaty complexity without knowing other usages. My hardware colleagues followed the recommended design from Abracon. Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] rtc: add Abracon ABx80x driver
On Tue, Mar 03, 2015 at 09:50:32PM +0100, Alexandre Belloni wrote:
> On 03/03/2015 at 12:20:12 -0800, Andrew Morton wrote :
> > On Tue, 3 Mar 2015 02:11:16 +0100 Alexandre Belloni
> > wrote:
> >
> > > On 02/03/2015 at 15:53:37 -0800, Andrew Morton wrote :
> > > > On Sun, 1 Mar 2015 11:27:15 +0100 Alexandre Belloni
> > > > wrote:
> > > >
> > > > > Add support for the i2c RTC from Abracon.
> > > >
> > > > What is the relationship between this patch and
> > > > http://ozlabs.org/~akpm/mmots/broken-out/rtc-add-rtc-abx805-a-driver-for-the-abracon-ab-1805-i2c-rtc.patch?
> > > >
> > >
> > > I'd say drop mine, I couldn't find the other one before writing it...
> > >
> > > I'll try to build on Philippe's driver.
> >
> > Which driver supports the most devices? Your driver has
> >
> > +static const struct i2c_device_id abx80x_id[] = {
> > + { "abx80x", ABX80X },
> > + { "ab0801", AB0801 },
> > + { "ab0802", AB0802 },
> > + { "ab0803", AB0803 },
> > + { "ab0804", AB0804 },
> > + { "ab0805", AB0805 },
> > + { "ab1801", AB1801 },
> > + { "ab1802", AB1802 },
> > + { "ab1803", AB1803 },
> > + { "ab1804", AB1804 },
> > + { "ab1805", AB1805 },
> > + { }
> > +};
> >
> > And Philippe's has
> >
> > +static struct i2c_device_id abx805_id[] = {
> > + { "abx805-rtc", 0 },
The only part my driver is actually tested with, is the 'AB1805', but see
below.
> > + { }
> > +};
> >
> >
> > And is the naming in Philippe's driver appropriate? If it supports the
> > AB1801 (for example) then why is it described as an "abx805" driver?
>
> The real naming is in the form ABx8yz. With:
>
> x: 0 or 1, indicate the presence of the reset management
> y: 0 or 1: 0 is i2c, 1 is spi
> z: [1-5]: different amount of on chip SRAM. From what I understand, only
> ABx8y5 are actually recommended for new designs.
My driver is based on the datashet called 'AB18X5 Real-Time Clock with
Power Management Family', which calls the parts 'AB18X5 family' with X
being '0' for I2c parts and '1' for SPI parts.
As the part I have and the driver I wrote are I2C, not SPI, I fixed the
'X' as 0 in the name of the driver.
The datasheet lists only one part as being 'software and pin compatible'
with the 'AB1805': the 'AB0805', hence the 'x' in the name I choose : abx805.
>
> They all share the same register set, apart from the reset management
> that is only available on AB18yz.
>
> >From my point of view, but I'm obviously biased, I'd take my patch
> because it declares and supports all the available rtc and it also uses
> the i2c_smbus_xxx API that is more robust than the raw i2c_transfer.
I have no opinion on that. The driver I started from uses 'raw i2c_transfer'.
>
> I also take care of the 12/24 mode bit and the write RTC bit which is
> necessary to be able to write to the RTC.
Actually, my driver is used in production and works fine, because the
default(reset) value of the 12/24 mode bit is '24 hour mode' and the
default value of the 'write RTC bit' enables writing. There is
no real need to play with them.
>
> What I like in Philippe's driver is the info printed at probe time and
> the support for trickle charging. However, I wouldn't enable it
> unconditionally.
My hardware colleagues told me that the only way to enable the 'ultra low-power'
functionality is enabling the trickle charger. And the 'ultra low-power'
functionality is the reason we choose that chip, so I would at least
keep that as the default behaviour.
Regards
Philippe
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] partitions: aix.c: off by one bug
On Tue, Aug 05, 2014 at 11:09:59AM +0300, Dan Carpenter wrote:
> The lvip[] array has "state->limit" elements so the condition here
> should be >= instead of >.
>
> Fixes: 6ceea22bbbc8 ('partitions: add aix lvm partition support files')
> Signed-off-by: Dan Carpenter
>
> diff --git a/block/partitions/aix.c b/block/partitions/aix.c
> index 0a6ed54..f3ed7b2 100644
> --- a/block/partitions/aix.c
> +++ b/block/partitions/aix.c
> @@ -253,7 +253,7 @@ int aix_partition(struct parsed_partitions *state)
> continue;
> }
> lv_ix = be16_to_cpu(p->lv_ix) - 1;
> - if (lv_ix > state->limit) {
> + if (lv_ix >= state->limit) {
> cur_lv_ix = -1;
> continue;
> }
Acked-by: Philippe De Muyter
Thanks
Did you encounter the bug in real life, or only by code review ?
If this has a real risk to happen, a pr_warn would be welcome.
Philippe
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH PING] VFS: mount must return EACCES, not EROFS
On Tue, Jul 08, 2014 at 02:02:18PM -0700, Andrew Morton wrote: > On Thu, 3 Jul 2014 18:29:19 +0200 Philippe De Muyter wrote: > > > On Wed, Jul 02, 2014 at 12:46:51PM -0700, Andrew Morton wrote: > > > On Fri, 27 Jun 2014 10:20:58 +0200 Philippe De Muyter > > > wrote: > > > > > > > Currently, the initial mount of the root file system by the linux > > > > kernel fails with a cryptic message instead of being retried with > > > > the MS_RDONLY flag set, when the device is read-only and the > > > > combination of block driver and filesystem driver yields EROFS. > > > > > > > > I do not know if POSIX mandates that mount(2) must fail with EACCES, nor > > > > if linux aims to strict compliance with POSIX on that point. Consensus > > > > amongst the messages that I have read so far seems to show that linux > > > > kernel hackers feel that EROFS is a more appropriate error code than > > > > EACCES in that case. > > > > > > Isn't the core problem that "the combination of block driver and > > > filesystem driver yields EROFS"? That the fs should instead be > > > returning EACCESS in this case? > > > > Does POSIX or Linux mandate that it should ? > > For info, SCO Unix documents that mount(2) may fail with EROFS : and adds "mount is not part of any currently supported standard" http://osr507doc.sco.com/en/man/html.S/mount.S.html Philippe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH PING] VFS: mount must return EACCES, not EROFS
On Wed, Jul 02, 2014 at 12:46:51PM -0700, Andrew Morton wrote:
> On Fri, 27 Jun 2014 10:20:58 +0200 Philippe De Muyter wrote:
>
> > Currently, the initial mount of the root file system by the linux
> > kernel fails with a cryptic message instead of being retried with
> > the MS_RDONLY flag set, when the device is read-only and the
> > combination of block driver and filesystem driver yields EROFS.
> >
> > I do not know if POSIX mandates that mount(2) must fail with EACCES, nor
> > if linux aims to strict compliance with POSIX on that point. Consensus
> > amongst the messages that I have read so far seems to show that linux
> > kernel hackers feel that EROFS is a more appropriate error code than
> > EACCES in that case.
>
> Isn't the core problem that "the combination of block driver and
> filesystem driver yields EROFS"? That the fs should instead be
> returning EACCESS in this case?
Does POSIX or Linux mandate that it should ?
>
> What fs and block driver are we talking about here, anyway?
The problem happened to me with a f2fs filesystem on a sd-card that was
accidentally write-protected and that was put in a SD-card slot (mmc block
driver).
I retested using mount(8) with a similar now intentionnaly write-protected
sd card in a usb reader (usb_storage driver ?) with vfat, f2fs and ext4
filesystems with the following results :
mywdesk:~ # strace -e mount mount /dev/sdb1 /mnt
mount("/dev/sdb1", "/mnt", "vfat", MS_MGC_VAL, NULL) = -1 EROFS (Read-only
file system)
mount: /dev/sdb1 is write-protected, mounting read-only
mount("/dev/sdb1", "/mnt", "vfat", MS_MGC_VAL|MS_RDONLY, NULL) = 0
+++ exited with 0 +++
mywdesk:~ # umount /mnt
mywdesk:~ # strace -e mount mount -t f2fs /dev/sdb2 /mnt
mount("/dev/sdb2", "/mnt", "f2fs", MS_MGC_VAL, NULL) = -1 EROFS (Read-only
file system)
mount: /dev/sdb2 is write-protected, mounting read-only
mount("/dev/sdb2", "/mnt", "f2fs", MS_MGC_VAL|MS_RDONLY, NULL) = 0
+++ exited with 0 +++
mywdesk:~ # umount /mnt
mywdesk:~ # strace -e mount mount /dev/sdb3 /mnt
mount("/dev/sdb3", "/mnt", "ext4", MS_MGC_VAL, NULL) = -1 EROFS (Read-only
file system)
mount: /dev/sdb3 is write-protected, mounting read-only
mount("/dev/sdb3", "/mnt", "ext4", MS_MGC_VAL|MS_RDONLY, NULL) = 0
+++ exited with 0 +++
mywdesk:~ #
All three file-systems (vfat, f2fs & ext4) yield EROFS.
I also quickly grepped for occurences of EROFS under fs/, and found no check
to replace EROFS by EACCES,
while the same grep under drivers/{block,cdrom,ide,md,memstick, mtd,
s390/block,scsi,usb} gives plenty of "return -EROFS;"
So, if no filesystem driver replaces EROFS by EACCES and many block drivers
return EROFS, it seems to me that many combinations will yield EROFS.
> >
> > So, do you choose for my first pragmatic and non-intrusive patch, that
> > lets mount_block_root() retry with MS_RDONLY if the file system
> > returns EROFS (https://lkml.org/lkml/2014/6/18/468) or for the second
> > one that forces all file-systems to return EACCES instead of EROFS.
> > (https://lkml.org/lkml/2014/6/20/98).
>
> They both seem a little hacky to me.
Actually I prefer my first patch, which simply adapts the kernel to the current
situation, like mount(8) already does, instead of trying to impose an ABI
change.
Philippe
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH PING] VFS: mount must return EACCES, not EROFS
PING Currently, the initial mount of the root file system by the linux kernel fails with a cryptic message instead of being retried with the MS_RDONLY flag set, when the device is read-only and the combination of block driver and filesystem driver yields EROFS. I do not know if POSIX mandates that mount(2) must fail with EACCES, nor if linux aims to strict compliance with POSIX on that point. Consensus amongst the messages that I have read so far seems to show that linux kernel hackers feel that EROFS is a more appropriate error code than EACCES in that case. So, do you choose for my first pragmatic and non-intrusive patch, that lets mount_block_root() retry with MS_RDONLY if the file system returns EROFS (https://lkml.org/lkml/2014/6/18/468) or for the second one that forces all file-systems to return EACCES instead of EROFS. (https://lkml.org/lkml/2014/6/20/98). Best regards Philippe On Fri, Jun 20, 2014 at 10:39:22AM +0200, Philippe De Muyter wrote: > mount must return EACCES, not EROFS, when one attempts to mount a > read-only filesystem in read-write mode, but the file-system layer > only transmits the error given by the block layer, and many block > drivers return EROFS in that case, so let's fix it in do_mount. > > Actually it is only a small problem for a user using the mount(1) > command, because EROFS is actually a more explicit answer than > EACCES, but init/do_mounts.c checks only for EACCES, not EROFS, > to decide to retry to mount the root file-system in read-only mode, > and so we are left with an unbootable kernel, and with a cryptic > error message (*) if the root partition happens to be read-only > > (*): VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): > error -30 > > Signed-off-by: Philippe De Muyter > Cc: Al Viro > Cc: Dave Chinner > Cc: Andrew Morton > Cc: linux-fsde...@vger.kernel.org > --- > fs/namespace.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/fs/namespace.c b/fs/namespace.c > index 182bc41..6291a3f 100644 > --- a/fs/namespace.c > +++ b/fs/namespace.c > @@ -2411,6 +2411,8 @@ long do_mount(const char *dev_name, const char > *dir_name, > > retval = security_sb_mount(dev_name, &path, > type_page, flags, data_page); > + if (retval == -EROFS) > + retval = -EACCES; > if (!retval && !may_mount()) > retval = -EPERM; > if (retval) > -- > 1.7.5.3 -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] init/do_mounts.c: treat EROFS like EACCES
On Fri, Jun 20, 2014 at 09:09:24AM +1000, Dave Chinner wrote: > On Thu, Jun 19, 2014 at 02:19:50PM -0700, Andrew Morton wrote: > > On Wed, 18 Jun 2014 18:12:44 +0200 Philippe De Muyter > > wrote: > > > > > some combinations of filesystem and block device (at least vfat on mmc) > > > yield -EROFS instead of -EACCES when the device is read-only. Retry > > > mounting with MS_RDONLY set, just like for the EACCES case, instead of > > > failing directly. > > > > > > ... > > > > > > --- a/init/do_mounts.c > > > +++ b/init/do_mounts.c > > > @@ -394,6 +394,7 @@ retry: > > > case 0: > > > goto out; > > > case -EACCES: > > > + case -EROFS: > > > flags |= MS_RDONLY; > > > goto retry; > > > case -EINVAL: > > > > hm, what's going on here. I'd have thought it to be very logical that > > file_system_type.mount() would return EROFS if the device is read-only! > > But I'm suspecting that there is some convention that the fs is > > supposed to return EACCES in this case. So *perhaps* it is vfat-on-mmc > > which needs fixing. Dunno. > > > > Al, are you able to shed light? > > from the mount(2) man page: > > EACCESA component of a path was not searchable. (See also > path_resolution(7).) Or, mounting a read-only filesystem > was attempted without giving the MS_RDONLY flag. Or, the > block device source is located on a filesystem mounted with > the MS_NODEV option. > > So, when the device is read-only, the error should EACCES, not > EROFS. Would seem to me that vfat-on-mmc needs fixing... Looking at the sources of mount(1) https://github.com/karelzak/util-linux/blob/master/sys-utils/mount.c at line 601, we clearly see that mount(1) allows mount(2) to fail with EROFS. We could as well fix the man page of mount(2) Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VFS: mount must return EACCES, not EROFS
mount must return EACCES, not EROFS, when one attempts to mount a read-only filesystem in read-write mode, but the file-system layer only transmits the error given by the block layer, and many block drivers return EROFS in that case, so let's fix it in do_mount. Actually it is only a small problem for a user using the mount(1) command, because EROFS is actually a more explicit answer than EACCES, but init/do_mounts.c checks only for EACCES, not EROFS, to decide to retry to mount the root file-system in read-only mode, and so we are left with an unbootable kernel, and with a cryptic error message (*) if the root partition happens to be read-only (*): VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): error -30 Signed-off-by: Philippe De Muyter Cc: Al Viro Cc: Dave Chinner Cc: Andrew Morton Cc: linux-fsde...@vger.kernel.org --- fs/namespace.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fs/namespace.c b/fs/namespace.c index 182bc41..6291a3f 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -2411,6 +2411,8 @@ long do_mount(const char *dev_name, const char *dir_name, retval = security_sb_mount(dev_name, &path, type_page, flags, data_page); + if (retval == -EROFS) + retval = -EACCES; if (!retval && !may_mount()) retval = -EPERM; if (retval) -- 1.7.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] init/do_mounts.c: treat EROFS like EACCES
some combinations of filesystem and block device (at least vfat on mmc) yield -EROFS instead of -EACCES when the device is read-only. Retry mounting with MS_RDONLY set, just like for the EACCES case, instead of failing directly. Signed-off-by: Philippe De Muyter Cc: Andrew Morton --- init/do_mounts.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/init/do_mounts.c b/init/do_mounts.c index 82f2288..af7b9b8 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -394,6 +394,7 @@ retry: case 0: goto out; case -EACCES: + case -EROFS: flags |= MS_RDONLY; goto retry; case -EINVAL: -- 1.7.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc: sdhci: Remove useless string-split's
Some error or warning messages that appear on one line in the kernel
log are split on two lines in sdhci.c although they are not too long
to fit on one 80-characters line.
This impairs grep'ping for them, so unsplit them.
Signed-off-by: Philippe De Muyter
---
drivers/mmc/host/sdhci.c | 29 ++---
1 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index bd8a098..9aa6483 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1226,8 +1226,8 @@ clock_set:
while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
& SDHCI_CLOCK_INT_STABLE)) {
if (timeout == 0) {
- pr_err("%s: Internal clock never "
- "stabilised.\n", mmc_hostname(host->mmc));
+ pr_err("%s: Internal clock never stabilised.\n",
+ mmc_hostname(host->mmc));
sdhci_dumpregs(host);
return;
}
@@ -1993,9 +1993,8 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32
opcode)
err = -EIO;
} else {
if (!(ctrl & SDHCI_CTRL_TUNED_CLK)) {
- pr_info(DRIVER_NAME ": Tuning procedure"
- " failed, falling back to fixed sampling"
- " clock\n");
+ pr_info(DRIVER_NAME ": Tuning procedure failed,"
+ " falling back to fixed sampling clock\n");
err = -EIO;
}
}
@@ -2192,8 +2191,8 @@ static void sdhci_timeout_timer(unsigned long data)
spin_lock_irqsave(&host->lock, flags);
if (host->mrq) {
- pr_err("%s: Timeout waiting for hardware "
- "interrupt.\n", mmc_hostname(host->mmc));
+ pr_err("%s: Timeout waiting for hardware interrupt.\n",
+ mmc_hostname(host->mmc));
sdhci_dumpregs(host);
if (host->data) {
@@ -2825,8 +2824,8 @@ int sdhci_add_host(struct sdhci_host *host)
if (host->flags & (SDHCI_USE_SDMA | SDHCI_USE_ADMA)) {
if (host->ops->enable_dma) {
if (host->ops->enable_dma(host)) {
- pr_warning("%s: No suitable DMA "
- "available. Falling back to PIO.\n",
+ pr_warn("%s: No suitable DMA available."
+ " Falling back to PIO.\n",
mmc_hostname(mmc));
host->flags &=
~(SDHCI_USE_SDMA | SDHCI_USE_ADMA);
@@ -2845,8 +2844,8 @@ int sdhci_add_host(struct sdhci_host *host)
if (!host->adma_desc || !host->align_buffer) {
kfree(host->adma_desc);
kfree(host->align_buffer);
- pr_warning("%s: Unable to allocate ADMA "
- "buffers. Falling back to standard DMA.\n",
+ pr_warn("%s: Unable to allocate ADMA buffers."
+ " Falling back to standard DMA.\n",
mmc_hostname(mmc));
host->flags &= ~SDHCI_USE_ADMA;
}
@@ -3138,8 +3137,8 @@ int sdhci_add_host(struct sdhci_host *host)
mmc->ocr_avail_mmc &= host->ocr_avail_mmc;
if (mmc->ocr_avail == 0) {
- pr_err("%s: Hardware doesn't report any "
- "support voltages.\n", mmc_hostname(mmc));
+ pr_err("%s: Hardware doesn't report any support voltages.\n",
+ mmc_hostname(mmc));
return -ENODEV;
}
@@ -3286,8 +3285,8 @@ void sdhci_remove_host(struct sdhci_host *host, int dead)
host->flags |= SDHCI_DEVICE_DEAD;
if (host->mrq) {
- pr_err("%s: Controller removed during "
- " transfer!\n", mmc_hostname(host->mmc));
+ pr_err("%s: Controller removed during transfer!\n",
+ mmc_hostname(host->mmc));
host->mrq->cmd->error = -ENOMEDIUM;
tasklet_schedule(&host->finish_tasklet);
--
1.7.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
mmc patch needed for 3.13 [was Re: ARM,sdhci_esdhc_imx: INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected]
Hi Chris & Shawn, The patch http://thread.gmane.org/gmane.linux.kernel.mmc/24371, that fixes a bug introduced in 3.13-rc1, is not in 3.13-rc8. Any chance to get it in 3.13 final ? Tested-by: Philippe De Muyter TIA Philippe On Tue, Jan 07, 2014 at 05:05:29PM +0800, Dong Aisheng wrote: > On Tue, Jan 07, 2014 at 10:22:54AM +0100, Philippe De Muyter wrote: > > Hi Shawn & Dong, > > > > On Sat, Dec 14, 2013 at 08:16:15PM +0800, Shawn Guo wrote: > > > On Fri, Dec 13, 2013 at 11:14:25PM +0100, Philippe De Muyter wrote: > > > > Hi Shawn, > > > > > > > > On Fri, Dec 13, 2013 at 09:34:32PM +0800, Shawn Guo wrote: > > > > > Hi Philippe, > > > > > > > > > > On Thu, Dec 12, 2013 at 03:49:25PM +0100, Philippe De Muyter wrote: > > > > > > Hello, > > > > > > > > > > > > I have just booted 3.13-rc3 on my i.MX6DL board, done nothing but > > > > > > watch > > > > > > it start, and I have got this! > > > > > > > > > > There is a patch [1] from Fabio for this issue. > > > > > > > > > > Shawn > > > > > > > > > > [1] http://thread.gmane.org/gmane.linux.kernel.mmc/23786 > > > > > > > > > > > == > > > > > > [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] > > > > ... > > > > > > > > Thanks. That fixed the problem. Will that go to 3.13 final ? > > > > > > That's a question for Chris. > > > > It seems that it has now been superseded by > > http://thread.gmane.org/gmane.linux.kernel.mmc/24371 > > > > Will those ones go in 3.13-rc8 and final ? > > > > I think patch 1 in that series is better to go in 3.13 final since the issue > exists > since 3.13 rc1. > > Patch 2 in that series is the fix for sdhci-esdhc-imx runtime pm which is > newly added in chris/mmc-next and seems target for 3.14. > > Chris, > Can we make it? > > Regards > Dong Aisheng -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM,sdhci_esdhc_imx: INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
Hi Shawn & Dong, On Sat, Dec 14, 2013 at 08:16:15PM +0800, Shawn Guo wrote: > On Fri, Dec 13, 2013 at 11:14:25PM +0100, Philippe De Muyter wrote: > > Hi Shawn, > > > > On Fri, Dec 13, 2013 at 09:34:32PM +0800, Shawn Guo wrote: > > > Hi Philippe, > > > > > > On Thu, Dec 12, 2013 at 03:49:25PM +0100, Philippe De Muyter wrote: > > > > Hello, > > > > > > > > I have just booted 3.13-rc3 on my i.MX6DL board, done nothing but watch > > > > it start, and I have got this! > > > > > > There is a patch [1] from Fabio for this issue. > > > > > > Shawn > > > > > > [1] http://thread.gmane.org/gmane.linux.kernel.mmc/23786 > > > > > > > == > > > > [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] > > ... > > > > Thanks. That fixed the problem. Will that go to 3.13 final ? > > That's a question for Chris. It seems that it has now been superseded by http://thread.gmane.org/gmane.linux.kernel.mmc/24371 Will those ones go in 3.13-rc8 and final ? TIA Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM,sdhci_esdhc_imx: INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
Hi Shawn, On Fri, Dec 13, 2013 at 09:34:32PM +0800, Shawn Guo wrote: > Hi Philippe, > > On Thu, Dec 12, 2013 at 03:49:25PM +0100, Philippe De Muyter wrote: > > Hello, > > > > I have just booted 3.13-rc3 on my i.MX6DL board, done nothing but watch > > it start, and I have got this! > > There is a patch [1] from Fabio for this issue. > > Shawn > > [1] http://thread.gmane.org/gmane.linux.kernel.mmc/23786 > > > == > > [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] ... Thanks. That fixed the problem. Will that go to 3.13 final ? Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ARM,sdhci_esdhc_imx: INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
>] process_one_work+0x1a4/0x444 [<8003ec7c>] worker_thread+0x120/0x3e4 [<8004539c>] kthread+0xcc/0xe8 [<8000e988>] ret_from_fork+0x14/0x2c stack backtrace: CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 3.13.0-rc3+ #4 Workqueue: kmmcd mmc_rescan Backtrace: [<80012218>] (dump_backtrace+0x0/0x10c) from [<800123b8>] (show_stack+0x18/0x1c) r6: r5:809c53f0 r4: r3:bf872d00 [<800123a0>] (show_stack+0x0/0x1c) from [<8064a720>] (dump_stack+0x78/0x94) [<8064a6a8>] (dump_stack+0x0/0x94) from [<8005f190>] (check_usage+0x43c/0x5f4) r4:0001 r3:bf872d00 [<8005ed54>] (check_usage+0x0/0x5f4) from [<8005f3a0>] (check_irq_usage+0x58/0xb4) [<8005f348>] (check_irq_usage+0x0/0xb4) from [<80060ce0>] (__lock_acquire+0x1124/0x1cc8) r8:bf8730e8 r7:809c53f0 r6:80e46a54 r5:bf8730d0 r4:0003 [<8005fbbc>] (__lock_acquire+0x0/0x1cc8) from [<80061d9c>] (lock_acquire+0x68/0x7c) [<80061d34>] (lock_acquire+0x0/0x7c) from [<8064f57c>] (mutex_lock_nested+0x5c/0x3b4) r7: r6:80dfc7bc r5:804b55b4 r4:808fd160 [<8064f520>] (mutex_lock_nested+0x0/0x3b4) from [<804b55b4>] (clk_prepare_lock+0x78/0xec) [<804b553c>] (clk_prepare_lock+0x0/0xec) from [<804b5fc8>] (clk_get_rate+0x14/0x64) r6:bf020c40 r5:000186a0 r4:bf828380 r3:80497c54 [<804b5fb4>] (clk_get_rate+0x0/0x64) from [<80497c74>] (esdhc_pltfm_set_clock+0x20/0x2a8) r5:000186a0 r4:bf020c40 [<80497c54>] (esdhc_pltfm_set_clock+0x0/0x2a8) from [<80492b60>] (sdhci_set_clock+0x4c/0x424) [<80492b14>] (sdhci_set_clock+0x0/0x424) from [<804944b8>] (sdhci_do_set_ios+0x314/0x728) [<804941a4>] (sdhci_do_set_ios+0x0/0x728) from [<804948f4>] (sdhci_set_ios+0x28/0x34) [<804948cc>] (sdhci_set_ios+0x0/0x34) from [<80481560>] (mmc_set_bus_mode+0x20/0x24) r5:806947d0 r4:bf020800 [<80481540>] (mmc_set_bus_mode+0x0/0x24) from [<804858d4>] (mmc_attach_mmc+0x140/0x1a0) [<80485794>] (mmc_attach_mmc+0x0/0x1a0) from [<80482348>] (mmc_rescan+0x28c/0x2dc) r5:806947d0 r4:bf020af8 [<804820bc>] (mmc_rescan+0x0/0x2dc) from [<8003df48>] (process_one_work+0x1a4/0x444) r7:bf9bc100 r6:bf80dc00 r5:bf020af8 r4:bf82d880 [<8003dda4>] (process_one_work+0x0/0x444) from [<8003ec7c>] (worker_thread+0x120/0x3e4) [<8003eb5c>] (worker_thread+0x0/0x3e4) from [<8004539c>] (kthread+0xcc/0xe8) [<800452d0>] (kthread+0x0/0xe8) from [<8000e988>] (ret_from_fork+0x14/0x2c) r7: r6: r5:800452d0 r4:bf840580 mmc2: BKOPS_EN bit is not set mmc2: new high speed MMC card at address 0001 -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] Add aix lvm partitions support files
On Fri, May 24, 2013 at 06:04:52AM -0400, Christoph Hellwig wrote: > On Tue, May 21, 2013 at 09:27:54AM +0200, Philippe De Muyter wrote: > > AIX LVM permits to make "logical volumes" which are made of multiple slices > > of multiple disks. The new code allows only access to the "logical volumes" > > which are made of one slice on the probed disk, a slice being a contiguous > > disk area. The code also detects "logical volumes" made of multiple slices > > on the probed disk, but can not describe them to the partition layer, > > because > > the partition layer generic code does not support that. When such > > non-contiguous "logical volumes" are detected, a diagnostic message is > > printed. > > This very much screams like it should be implemented in the lvm2 > userspace package using the dm kernel driver. Is lvm2 a generic tool for discovering foreign partition layouts, or it is about one linux-specific lvm implementation ? Philippe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] Add aix lvm partitions support files
Hi Andrew, On Mon, May 20, 2013 at 04:39:27PM -0700, Andrew Morton wrote: > On Mon, 29 Apr 2013 23:18:30 +0200 Philippe De Muyter wrote: > > > adding partitions/aix.h and partitions/aix.c > > > > Partitions (called Logical Volumes in AIX) can be non-contiguous or > > even split on more than one disk. Altough we detect such partitions, > > we cannot describe them to the Linux partitions layer, so we simply > > discard them and issue a diagnose message. > > This description is rather hard to follow. > > It appears that the new code permits Linux to access some types of AIX > partitions, but not other types, correct? If so, can we please provide > a more explicit description of which typesw are and are not supported? > AIX LVM permits to make "logical volumes" which are made of multiple slices of multiple disks. The new code allows only access to the "logical volumes" which are made of one slice on the probed disk, a slice being a contiguous disk area. The code also detects "logical volumes" made of multiple slices on the probed disk, but can not describe them to the partition layer, because the partition layer generic code does not support that. When such non-contiguous "logical volumes" are detected, a diagnostic message is printed. Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] partitions/msdos: enumerate also AIX LVM partitions
Hi Andrew,
On Mon, May 20, 2013 at 04:41:52PM -0700, Andrew Morton wrote:
> On Mon, 29 Apr 2013 23:18:31 +0200 Philippe De Muyter wrote:
>
> > Graft AIX partitions enumeration in partitions/msdos.c
> >
> > There is already a AIX disks detection logic in msdos.c. When an
> > AIX disk has been found, and if configured to, call the aix partitions
> > recognizer. This avoids removal of AIX disks protection from msdos.c,
> > avoids code duplication, and ensures that AIX partitions enumeration
> > is called before plain msdos partitions enumeration.
> >
> > ...
> >
> > --- a/block/partitions/msdos.c
> > +++ b/block/partitions/msdos.c
> > @@ -23,6 +23,7 @@
> > #include "check.h"
> > #include "msdos.h"
> > #include "efi.h"
> > +#include "aix.h"
> >
> > /*
> > * Many architectures don't like unaligned accesses, while
> > @@ -462,8 +463,12 @@ int msdos_partition(struct parsed_partitions *state)
> > */
> > if (aix_magic_present(state, data)) {
> > put_dev_sector(sect);
> > +#ifdef CONFIG_AIX_PARTITION
> > + return aix_partition(state);
> > +#else
> > strlcat(state->pp_buf, " [AIX]", PAGE_SIZE);
> > return 0;
> > +#endif
> > }
> >
> > if (!msdos_magic_present(data + 510)) {
>
> hm, what's going on here.
>
> Why does partitions/msdos.c know about AIX at all? Is there something
> special about AIX partitioning which ties it in with msdos?
Well, PowerPC BIOS (PPCBUG or Open Firmware) mimics PC BIOS and requires the
first block of the disk to describe the boot partition the same way that
PC BIOS does. Remember, the aim of IBM, Motorola and Apple was to replace
the PC's by PowerPC's :). So, an AIX disk can erroneously be recognized as
a dos disk with two partitions (two times the same boot partition). That's
the reason why there is already code in block/partitions/msdos.c to avoid
that.
>
> Now that we have AIX partitioning support, can we simply remove the AIX
> code from msdos.c? So msdos.c will say "I don't know what that is",
> and we fall through to aix.c which says "that's mine!"?
I didn't want to remove the AIX protection from msdos.c, for the likely case
that someone would compile the kernel without AIX_PARTITION support, And, as
a part of the AIX detection was already done by 'aix_magic_present', I did
not want to duplicate it. I can move the AIX detection logic to aix.c and
still keep the AIX protection for msdos.c with some more #ifdef's if you prefer.
Philippe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
AIX LVM support : block/partitions, kpartx, dmraid or lvm2 or ...
Hello, I have recently written a read-only support for linux for AIX 3 & 4 lvm disks, and submitted a patch for the linux block/partitions subsystem, for which I have no feedback yet. Now I wonder, as AIX LVM can describe mirrored and splitted logical volumes, is block/partitions the right place for it ? It seems that only contiguous partitions can be described. Am I mistaken ? I looked also at kpartx, but it seems to me that kpartx has the same limitations as block/partitions. Should I rather make a patch for dmraid or lvm2 or some other tool I am not aware of ? What would be the best place for that support ? I have working code that can generate tables for dmsetup, and I know there is some demand for AIX LVM and AIX JFS support in linux, but where should I send it ? Thanks in advance Philippe PS: Of course, AIX LVM support does only make sense if AIX JFS file systems are supported. I have written read-only support for cwAIX JFSit also, and I plan to submit it when I have a solution for AIX LVM, so that the AIX JFS code can be tested by others. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] partitions/Makefile: compile aix.c if configured.
From: Philippe De Muyter Signed-off-by: Philippe De Muyter Cc: Karel Zak Cc: Jens Axboe Cc: Andrew Morton --- block/partitions/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/block/partitions/Makefile b/block/partitions/Makefile index 03af8ea..2be4d7b 100644 --- a/block/partitions/Makefile +++ b/block/partitions/Makefile @@ -7,6 +7,7 @@ obj-$(CONFIG_BLOCK) := check.o obj-$(CONFIG_ACORN_PARTITION) += acorn.o obj-$(CONFIG_AMIGA_PARTITION) += amiga.o obj-$(CONFIG_ATARI_PARTITION) += atari.o +obj-$(CONFIG_AIX_PARTITION) += aix.o obj-$(CONFIG_MAC_PARTITION) += mac.o obj-$(CONFIG_LDM_PARTITION) += ldm.o obj-$(CONFIG_MSDOS_PARTITION) += msdos.o -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] partitions/Kconfig: add the AIX_PARTITION entry
From: Philippe De Muyter This is the final patch enabling a user to select AIX lvm partitions detection. Signed-off-by: Philippe De Muyter Cc: Karel Zak Cc: Jens Axboe Cc: Andrew Morton --- block/partitions/Kconfig | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/block/partitions/Kconfig b/block/partitions/Kconfig index 75a54e1..4cebb2f 100644 --- a/block/partitions/Kconfig +++ b/block/partitions/Kconfig @@ -68,6 +68,17 @@ config ACORN_PARTITION_RISCIX of machines called RISCiX. If you say 'Y' here, Linux will be able to read disks partitioned under RISCiX. +config AIX_PARTITION + bool "AIX basic partition table support" if PARTITION_ADVANCED + help + Say Y here if you would like to be able to read the hard disk + partition table format used by IBM or Motorola PowerPC machines + running AIX. AIX actually uses a Logical Volume Manager, where + "logical volumes" can be spread across one or multiple disks, + but this driver works only for the simple case of partitions which + are contiguous. + Otherwise, say N. + config OSF_PARTITION bool "Alpha OSF partition support" if PARTITION_ADVANCED default y if ALPHA -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] partitions/msdos: enumerate also AIX LVM partitions
From: Philippe De Muyter
Graft AIX partitions enumeration in partitions/msdos.c
There is already a AIX disks detection logic in msdos.c. When an
AIX disk has been found, and if configured to, call the aix partitions
recognizer. This avoids removal of AIX disks protection from msdos.c,
avoids code duplication, and ensures that AIX partitions enumeration
is called before plain msdos partitions enumeration.
Signed-off-by: Philippe De Muyter
Cc: Karel Zak
Cc: Jens Axboe
Cc: Andrew Morton
---
block/partitions/msdos.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/block/partitions/msdos.c b/block/partitions/msdos.c
index 9bf19e6..9123f25 100644
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -23,6 +23,7 @@
#include "check.h"
#include "msdos.h"
#include "efi.h"
+#include "aix.h"
/*
* Many architectures don't like unaligned accesses, while
@@ -462,8 +463,12 @@ int msdos_partition(struct parsed_partitions *state)
*/
if (aix_magic_present(state, data)) {
put_dev_sector(sect);
+#ifdef CONFIG_AIX_PARTITION
+ return aix_partition(state);
+#else
strlcat(state->pp_buf, " [AIX]", PAGE_SIZE);
return 0;
+#endif
}
if (!msdos_magic_present(data + 510)) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] partitions/msdos.c: end-of-line whitespace and semicolon cleanup
From: Philippe De Muyter
Signed-off-by: Philippe De Muyter
Cc: Karel Zak
Cc: Jens Axboe
Cc: Andrew Morton
---
block/partitions/msdos.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/block/partitions/msdos.c b/block/partitions/msdos.c
index 7681cd2..9bf19e6 100644
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -90,7 +90,7 @@ static int aix_magic_present(struct parsed_partitions *state,
unsigned char *p)
if (d[0] == '_' && d[1] == 'L' && d[2] == 'V' && d[3] == 'M')
ret = 1;
put_dev_sector(sect);
- };
+ }
return ret;
}
@@ -142,7 +142,7 @@ static void parse_extended(struct parsed_partitions *state,
return;
if (!msdos_magic_present(data + 510))
- goto done;
+ goto done;
p = (struct partition *) (data + 0x1be);
@@ -155,7 +155,7 @@ static void parse_extended(struct parsed_partitions *state,
* and OS/2 seems to use all four entries.
*/
- /*
+ /*
* First process the data partition(s)
*/
for (i=0; i<4; i++, p++) {
@@ -263,7 +263,7 @@ static void parse_solaris_x86(struct parsed_partitions
*state,
}
#if defined(CONFIG_BSD_DISKLABEL)
-/*
+/*
* Create devices for BSD partitions listed in a disklabel, under a
* dos-like partition. See parse_extended() for more information.
*/
@@ -294,7 +294,7 @@ static void parse_bsd(struct parsed_partitions *state,
if (state->next == state->limit)
break;
- if (p->p_fstype == BSD_FS_UNUSED)
+ if (p->p_fstype == BSD_FS_UNUSED)
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
@@ -441,7 +441,7 @@ static struct {
{NEW_SOLARIS_X86_PARTITION, parse_solaris_x86},
{0, NULL},
};
-
+
int msdos_partition(struct parsed_partitions *state)
{
sector_t sector_size = bdev_logical_block_size(state->bdev) / 512;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] partitions: Add aix lvm partitions support files
From: Philippe De Muyter
adding partitions/aix.h and partitions/aix.c
Partitions (called Logical Volumes in AIX) can be non-contiguous or
even split on more than one disk. Altough we detect such partitions,
we cannot describe them to the Linux partitions layer, so we simply
discard them and issue a diagnose message.
Signed-off-by: Philippe De Muyter
Cc: Karel Zak
Cc: Jens Axboe
Cc: Andrew Morton
---
block/partitions/aix.c | 291
block/partitions/aix.h |1 +
2 files changed, 292 insertions(+), 0 deletions(-)
create mode 100644 block/partitions/aix.c
create mode 100644 block/partitions/aix.h
diff --git a/block/partitions/aix.c b/block/partitions/aix.c
new file mode 100644
index 000..ef46cf3
--- /dev/null
+++ b/block/partitions/aix.c
@@ -0,0 +1,291 @@
+/*
+ * fs/partitions/aix.c
+ *
+ * Copyright (C) 2012-2013 Philippe De Muyter
+ */
+
+#include "check.h"
+#include "aix.h"
+
+struct lvm_rec {
+ char lvm_id[4]; /* "_LVM" */
+ char reserved4[16];
+ __be32 lvmarea_len;
+ __be32 vgda_len;
+ __be32 vgda_psn[2];
+ char reserved36[10];
+ __be16 pp_size; /* log2(pp_size) */
+ char reserved46[12];
+ __be16 version;
+ };
+
+struct vgda {
+ __be32 secs;
+ __be32 usec;
+ char reserved8[16];
+ __be16 numlvs;
+ __be16 maxlvs;
+ __be16 pp_size;
+ __be16 numpvs;
+ __be16 total_vgdas;
+ __be16 vgda_size;
+ };
+
+struct lvd {
+ __be16 lv_ix;
+ __be16 res2;
+ __be16 res4;
+ __be16 maxsize;
+ __be16 lv_state;
+ __be16 mirror;
+ __be16 mirror_policy;
+ __be16 num_lps;
+ __be16 res10[8];
+ };
+
+struct lvname {
+ char name[64];
+ };
+
+struct ppe {
+ __be16 lv_ix;
+ unsigned short res2;
+ unsigned short res4;
+ __be16 lp_ix;
+ unsigned short res8[12];
+ };
+
+struct pvd {
+ char reserved0[16];
+ __be16 pp_count;
+ char reserved18[2];
+ __be32 psn_part1;
+ char reserved24[8];
+ struct ppe ppe[1016];
+ };
+
+#define LVM_MAXLVS 256
+
+/**
+ * last_lba(): return number of last logical block of device
+ * @bdev: block device
+ *
+ * Description: Returns last LBA value on success, 0 on error.
+ * This is stored (by sd and ide-geometry) in
+ * the part[0] entry for this disk, and is the number of
+ * physical sectors available on the disk.
+ */
+static u64 last_lba(struct block_device *bdev)
+{
+ if (!bdev || !bdev->bd_inode)
+ return 0;
+ return (bdev->bd_inode->i_size >> 9) - 1ULL;
+}
+
+/**
+ * read_lba(): Read bytes from disk, starting at given LBA
+ * @state
+ * @lba
+ * @buffer
+ * @count
+ *
+ * Description: Reads @count bytes from @state->bdev into @buffer.
+ * Returns number of bytes read on success, 0 on error.
+ */
+static size_t read_lba(struct parsed_partitions *state, u64 lba, u8 * buffer,
size_t count)
+{
+ size_t totalreadcount = 0;
+
+ if (!buffer || lba + count / 512 > last_lba(state->bdev))
+return 0;
+
+ while (count) {
+ int copied = 512;
+ Sector sect;
+ unsigned char *data = read_part_sector(state, lba++, §);
+ if (!data)
+ break;
+ if (copied > count)
+ copied = count;
+ memcpy(buffer, data, copied);
+ put_dev_sector(sect);
+ buffer += copied;
+ totalreadcount +=copied;
+ count -= copied;
+ }
+ return totalreadcount;
+}
+
+/**
+ * alloc_pvd(): reads physical volume descriptor
+ * @state
+ * @lba
+ *
+ * Description: Returns pvd on success, NULL on error.
+ * Allocates space for pvd and fill it with disk blocks at @lba
+ * Notes: remember to free pvd when you're done!
+ */
+static struct pvd *alloc_pvd(struct parsed_partitions *state, u32 lba)
+{
+ size_t count = sizeof(struct pvd);
+ struct pvd *p;
+
+ p = kmalloc(count, GFP_KERNEL);
+ if (!p)
+ return NULL;
+
+ if (read_lba(state, lba, (u8 *) p, count) < count) {
+ kfree(p);
+ return NULL;
+ }
+ return p;
+}
+
+/**
+ * alloc_lvn(): reads logical volume names
+ * @state
+ * @lba
+ *
+ * Description: Returns lvn on success, NULL on error.
+ * Allocates space for lvn and fill it with disk blocks at @lba
+ * Notes: remember to free lvn when you're done!
+ */
+static struct lvname *alloc_lvn(struct parsed_partitions *state, u32 lba)
+{
+ size_t count = sizeof(struct lvname) * LVM_MAXLVS;
+ struct lvname *p;
+
+ p = kmalloc(count, GFP_KERNEL);
+ if (!p)
+ return NULL;
+
+ if (read_lba(state, lba, (u8 *) p, count) < count) {
+ kfree(p);
+
[PATCH v3 0/5] partitions: Add aix lvm partitions support
This is the version 3 of my patchset to add a basic aix lvm partitions parser to linux. The only modified patch is patch 2. It fixes a problem in the discovering of small (1 pp) partitions in presence of discontiguous partitions. Jens, patch 1 is actually just a cleanup of msdos.c. You could apply it already even if you delay the decision for the other ones, so I could stop resending it here, as patch 3 depends on it. Philippe [PATCH 1/5] partitions/msdos.c: end-of-line whitespace and semicolon cleanup [PATCH 2/5] partitions: Add aix lvm partitions support files [PATCH 3/5] partitions/msdos: enumerate also AIX LVM partitions [PATCH 4/5] partitions/Makefile: compile aix.c if configured. [PATCH 5/5] partitions/Kconfig: add the AIX_PARTITION entry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] Add aix lvm partitions support files
On Tue, Apr 30, 2013 at 09:18:40AM +0200, Philippe De Muyter wrote: > On Tue, Apr 30, 2013 at 09:08:40AM +0200, Philippe De Muyter wrote: > > On Mon, Apr 29, 2013 at 11:50:51PM +0200, Philippe De Muyter wrote: > > > On Mon, Apr 29, 2013 at 01:40:41PM +0200, Philippe De Muyter wrote: > > > > On Mon, Apr 29, 2013 at 11:37:56AM +0200, Karel Zak wrote: > > > > > > > > > > Philippe, do you have any disk image with AIX LVM? It would be nice to > > > > > have a way how to test the code. I'd like to add support for AIX to > > > > > libblkid too. > > > > > > > > Of course. But that's not a couple of blocks. I'll try to cut the > > > > slice that you need. > > > > > > Here is one example. I'll try to send another one tomorrow. > > > > Here is the other example. > > And here is a third one And now a fourth one, this one with partitions that are not contiguous. Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles aixlvmhdr-136g.bz2 Description: application/bzip
Re: [PATCH 2/5] Add aix lvm partitions support files
On Tue, Apr 30, 2013 at 09:08:40AM +0200, Philippe De Muyter wrote: > On Mon, Apr 29, 2013 at 11:50:51PM +0200, Philippe De Muyter wrote: > > On Mon, Apr 29, 2013 at 01:40:41PM +0200, Philippe De Muyter wrote: > > > On Mon, Apr 29, 2013 at 11:37:56AM +0200, Karel Zak wrote: > > > > > > > > Philippe, do you have any disk image with AIX LVM? It would be nice to > > > > have a way how to test the code. I'd like to add support for AIX to > > > > libblkid too. > > > > > > Of course. But that's not a couple of blocks. I'll try to cut the > > > slice that you need. > > > > Here is one example. I'll try to send another one tomorrow. > > Here is the other example. And here is a third one Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles aixlvmhdr-jori.bz2 Description: application/bzip
Re: [PATCH 2/5] Add aix lvm partitions support files
On Mon, Apr 29, 2013 at 11:50:51PM +0200, Philippe De Muyter wrote: > On Mon, Apr 29, 2013 at 01:40:41PM +0200, Philippe De Muyter wrote: > > On Mon, Apr 29, 2013 at 11:37:56AM +0200, Karel Zak wrote: > > > > > > Philippe, do you have any disk image with AIX LVM? It would be nice to > > > have a way how to test the code. I'd like to add support for AIX to > > > libblkid too. > > > > Of course. But that's not a couple of blocks. I'll try to cut the > > slice that you need. > > Here is one example. I'll try to send another one tomorrow. Here is the other example. Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles aixlvmhdr-goofy.bz2 Description: application/bzip
Re: [PATCH 2/5] Add aix lvm partitions support files
On Tue, Apr 30, 2013 at 08:41:52AM +0200, Jens Axboe wrote: > On Mon, Apr 29 2013, Philippe De Muyter wrote: > > > > so sda is 8,0 and sdb is 8,16 > > > > and if, while discovering partitions of /dev/sda, I try to make a > > partition 16 or higher, it is silently discarded by 'put_partition'. > > > > Is that changed ? > > That's a set limitation of sd, it does not apply to other devices. The > legacy IDE code used 64 for max partitions, for instance. So Karel is > right, you should not make any assumptions about the max number of > partitions, it is driver dependent. I replaced that by state->limit in the v2 series. Philippe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] Add aix lvm partitions support files
On Mon, Apr 29, 2013 at 01:40:41PM +0200, Philippe De Muyter wrote: > On Mon, Apr 29, 2013 at 11:37:56AM +0200, Karel Zak wrote: > > > > Philippe, do you have any disk image with AIX LVM? It would be nice to > > have a way how to test the code. I'd like to add support for AIX to > > libblkid too. > > Of course. But that's not a couple of blocks. I'll try to cut the > slice that you need. Here is one example. I'll try to send another one tomorrow. Philippe aixlvmhdr-128g.bz2 Description: application/bzip
[PATCH 2/5] Add aix lvm partitions support files
adding partitions/aix.h and partitions/aix.c
Partitions (called Logical Volumes in AIX) can be non-contiguous or
even split on more than one disk. Altough we detect such partitions,
we cannot describe them to the Linux partitions layer, so we simply
discard them and issue a diagnose message.
Signed-off-by: Philippe De Muyter
Cc: Karel Zak
Cc: Jens Axboe
Cc: Andrew Morton
---
block/partitions/aix.c | 290
block/partitions/aix.h |1 +
2 files changed, 291 insertions(+), 0 deletions(-)
create mode 100644 block/partitions/aix.c
create mode 100644 block/partitions/aix.h
diff --git a/block/partitions/aix.c b/block/partitions/aix.c
new file mode 100644
index 000..b3288d2
--- /dev/null
+++ b/block/partitions/aix.c
@@ -0,0 +1,290 @@
+/*
+ * fs/partitions/aix.c
+ *
+ * Copyright (C) 2012-2013 Philippe De Muyter
+ */
+
+#include "check.h"
+#include "aix.h"
+
+struct lvm_rec {
+ char lvm_id[4]; /* "_LVM" */
+ char reserved4[16];
+ __be32 lvmarea_len;
+ __be32 vgda_len;
+ __be32 vgda_psn[2];
+ char reserved36[10];
+ __be16 pp_size; /* log2(pp_size) */
+ char reserved46[12];
+ __be16 version;
+ };
+
+struct vgda {
+ __be32 secs;
+ __be32 usec;
+ char reserved8[16];
+ __be16 numlvs;
+ __be16 maxlvs;
+ __be16 pp_size;
+ __be16 numpvs;
+ __be16 total_vgdas;
+ __be16 vgda_size;
+ };
+
+struct lvd {
+ __be16 lv_ix;
+ __be16 res2;
+ __be16 res4;
+ __be16 maxsize;
+ __be16 lv_state;
+ __be16 mirror;
+ __be16 mirror_policy;
+ __be16 num_lps;
+ __be16 res10[8];
+ };
+
+struct lvname {
+ char name[64];
+ };
+
+struct ppe {
+ __be16 lv_ix;
+ unsigned short res2;
+ unsigned short res4;
+ __be16 lp_ix;
+ unsigned short res8[12];
+ };
+
+struct pvd {
+ char reserved0[16];
+ __be16 pp_count;
+ char reserved18[2];
+ __be32 psn_part1;
+ char reserved24[8];
+ struct ppe ppe[1016];
+ };
+
+#define LVM_MAXLVS 256
+
+/**
+ * last_lba(): return number of last logical block of device
+ * @bdev: block device
+ *
+ * Description: Returns last LBA value on success, 0 on error.
+ * This is stored (by sd and ide-geometry) in
+ * the part[0] entry for this disk, and is the number of
+ * physical sectors available on the disk.
+ */
+static u64 last_lba(struct block_device *bdev)
+{
+ if (!bdev || !bdev->bd_inode)
+ return 0;
+ return (bdev->bd_inode->i_size >> 9) - 1ULL;
+}
+
+/**
+ * read_lba(): Read bytes from disk, starting at given LBA
+ * @state
+ * @lba
+ * @buffer
+ * @count
+ *
+ * Description: Reads @count bytes from @state->bdev into @buffer.
+ * Returns number of bytes read on success, 0 on error.
+ */
+static size_t read_lba(struct parsed_partitions *state, u64 lba, u8 * buffer,
size_t count)
+{
+ size_t totalreadcount = 0;
+
+ if (!buffer || lba + count / 512 > last_lba(state->bdev))
+return 0;
+
+ while (count) {
+ int copied = 512;
+ Sector sect;
+ unsigned char *data = read_part_sector(state, lba++, §);
+ if (!data)
+ break;
+ if (copied > count)
+ copied = count;
+ memcpy(buffer, data, copied);
+ put_dev_sector(sect);
+ buffer += copied;
+ totalreadcount +=copied;
+ count -= copied;
+ }
+ return totalreadcount;
+}
+
+/**
+ * alloc_pvd(): reads physical volume descriptor
+ * @state
+ * @lba
+ *
+ * Description: Returns pvd on success, NULL on error.
+ * Allocates space for pvd and fill it with disk blocks at @lba
+ * Notes: remember to free pvd when you're done!
+ */
+static struct pvd *alloc_pvd(struct parsed_partitions *state, u32 lba)
+{
+ size_t count = sizeof(struct pvd);
+ struct pvd *p;
+
+ p = kmalloc(count, GFP_KERNEL);
+ if (!p)
+ return NULL;
+
+ if (read_lba(state, lba, (u8 *) p, count) < count) {
+ kfree(p);
+ return NULL;
+ }
+ return p;
+}
+
+/**
+ * alloc_lvn(): reads logical volume names
+ * @state
+ * @lba
+ *
+ * Description: Returns lvn on success, NULL on error.
+ * Allocates space for lvn and fill it with disk blocks at @lba
+ * Notes: remember to free lvn when you're done!
+ */
+static struct lvname *alloc_lvn(struct parsed_partitions *state, u32 lba)
+{
+ size_t count = sizeof(struct lvname) * LVM_MAXLVS;
+ struct lvname *p;
+
+ p = kmalloc(count, GFP_KERNEL);
+ if (!p)
+ return NULL;
+
+ if (read_lba(state, lba, (u8 *) p, count) < count) {
+ kfree(p);
+ return NULL;
+ }
[PATCH v2 0/5] partitions: add AIX LVM support
This is a revision of the patch serie I sent some days ago, with fixes based on observations by Karel Zak, and other cleanups. This enables finding the contiguous partitions in AIX LVM disks. Patch 1 is actually just a cleanup of msdos.c, but as patch 3 depends on it I prefer to put it here. Philippe [PATCH 1/5] partitions/msdos.c: end-of-line whitespace and semicolon cleanup [PATCH 2/5] Add aix lvm partitions support files [PATCH 3/5] partitions/msdos: enumerate also AIX LVM partitions [PATCH 4/5] partitions/Makefile: compile aix.c if configured. [PATCH 5/5] partitions/Kconfig: add the AIX_PARTITION entry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] partitions/msdos: enumerate also AIX LVM partitions
Graft AIX partitions enumeration in partitions/msdos.c
There is already a AIX disks detection logic in msdos.c. When an
AIX disk has been found, and if configured to, call the aix partitions
recognizer. This avoids removal of AIX disks protection from msdos.c,
avoids code duplication, and ensures that AIX partitions enumeration
is called before plain msdos partitions enumeration.
Signed-off-by: Philippe De Muyter
Cc: Karel Zak
Cc: Jens Axboe
Cc: Andrew Morton
---
block/partitions/msdos.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/block/partitions/msdos.c b/block/partitions/msdos.c
index 9bf19e6..9123f25 100644
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -23,6 +23,7 @@
#include "check.h"
#include "msdos.h"
#include "efi.h"
+#include "aix.h"
/*
* Many architectures don't like unaligned accesses, while
@@ -462,8 +463,12 @@ int msdos_partition(struct parsed_partitions *state)
*/
if (aix_magic_present(state, data)) {
put_dev_sector(sect);
+#ifdef CONFIG_AIX_PARTITION
+ return aix_partition(state);
+#else
strlcat(state->pp_buf, " [AIX]", PAGE_SIZE);
return 0;
+#endif
}
if (!msdos_magic_present(data + 510)) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] partitions/Kconfig: add the AIX_PARTITION entry
This is the final patch enabling a user to select AIX lvm partitions detection. Signed-off-by: Philippe De Muyter Cc: Karel Zak Cc: Jens Axboe Cc: Andrew Morton --- block/partitions/Kconfig | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/block/partitions/Kconfig b/block/partitions/Kconfig index 75a54e1..4cebb2f 100644 --- a/block/partitions/Kconfig +++ b/block/partitions/Kconfig @@ -68,6 +68,17 @@ config ACORN_PARTITION_RISCIX of machines called RISCiX. If you say 'Y' here, Linux will be able to read disks partitioned under RISCiX. +config AIX_PARTITION + bool "AIX basic partition table support" if PARTITION_ADVANCED + help + Say Y here if you would like to be able to read the hard disk + partition table format used by IBM or Motorola PowerPC machines + running AIX. AIX actually uses a Logical Volume Manager, where + "logical volumes" can be spread across one or multiple disks, + but this driver works only for the simple case of partitions which + are contiguous. + Otherwise, say N. + config OSF_PARTITION bool "Alpha OSF partition support" if PARTITION_ADVANCED default y if ALPHA -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] partitions/Makefile: compile aix.c if configured.
Signed-off-by: Philippe De Muyter Cc: Karel Zak Cc: Jens Axboe Cc: Andrew Morton --- block/partitions/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/block/partitions/Makefile b/block/partitions/Makefile index 03af8ea..2be4d7b 100644 --- a/block/partitions/Makefile +++ b/block/partitions/Makefile @@ -7,6 +7,7 @@ obj-$(CONFIG_BLOCK) := check.o obj-$(CONFIG_ACORN_PARTITION) += acorn.o obj-$(CONFIG_AMIGA_PARTITION) += amiga.o obj-$(CONFIG_ATARI_PARTITION) += atari.o +obj-$(CONFIG_AIX_PARTITION) += aix.o obj-$(CONFIG_MAC_PARTITION) += mac.o obj-$(CONFIG_LDM_PARTITION) += ldm.o obj-$(CONFIG_MSDOS_PARTITION) += msdos.o -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] partitions/msdos.c: end-of-line whitespace and semicolon cleanup
Signed-off-by: Philippe De Muyter
Cc: Karel Zak
Cc: Jens Axboe
Cc: Andrew Morton
---
block/partitions/msdos.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/block/partitions/msdos.c b/block/partitions/msdos.c
index 7681cd2..9bf19e6 100644
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -90,7 +90,7 @@ static int aix_magic_present(struct parsed_partitions *state,
unsigned char *p)
if (d[0] == '_' && d[1] == 'L' && d[2] == 'V' && d[3] == 'M')
ret = 1;
put_dev_sector(sect);
- };
+ }
return ret;
}
@@ -142,7 +142,7 @@ static void parse_extended(struct parsed_partitions *state,
return;
if (!msdos_magic_present(data + 510))
- goto done;
+ goto done;
p = (struct partition *) (data + 0x1be);
@@ -155,7 +155,7 @@ static void parse_extended(struct parsed_partitions *state,
* and OS/2 seems to use all four entries.
*/
- /*
+ /*
* First process the data partition(s)
*/
for (i=0; i<4; i++, p++) {
@@ -263,7 +263,7 @@ static void parse_solaris_x86(struct parsed_partitions
*state,
}
#if defined(CONFIG_BSD_DISKLABEL)
-/*
+/*
* Create devices for BSD partitions listed in a disklabel, under a
* dos-like partition. See parse_extended() for more information.
*/
@@ -294,7 +294,7 @@ static void parse_bsd(struct parsed_partitions *state,
if (state->next == state->limit)
break;
- if (p->p_fstype == BSD_FS_UNUSED)
+ if (p->p_fstype == BSD_FS_UNUSED)
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
@@ -441,7 +441,7 @@ static struct {
{NEW_SOLARIS_X86_PARTITION, parse_solaris_x86},
{0, NULL},
};
-
+
int msdos_partition(struct parsed_partitions *state)
{
sector_t sector_size = bdev_logical_block_size(state->bdev) / 512;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] partitions/efi.c: replace useless kzalloc's by kmalloc's
In alloc_read_gpt_entries and alloc_read_gpt_header, the kzalloc'ated zones are either totally overwritten by the following read_lba call, or freed. As kmalloc is cheaper than kzalloc, use kmalloc. Signed-off-by: Philippe De Muyter Cc: Matt Domsch Cc: Panagiotis Issaris Cc: Jens Axboe Cc: Andrew Morton --- block/partitions/efi.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/block/partitions/efi.c b/block/partitions/efi.c index ff5804e..c85fc89 100644 --- a/block/partitions/efi.c +++ b/block/partitions/efi.c @@ -238,7 +238,7 @@ static gpt_entry *alloc_read_gpt_entries(struct parsed_partitions *state, le32_to_cpu(gpt->sizeof_partition_entry); if (!count) return NULL; - pte = kzalloc(count, GFP_KERNEL); + pte = kmalloc(count, GFP_KERNEL); if (!pte) return NULL; @@ -267,7 +267,7 @@ static gpt_header *alloc_read_gpt_header(struct parsed_partitions *state, gpt_header *gpt; unsigned ssz = bdev_logical_block_size(state->bdev); - gpt = kzalloc(ssz, GFP_KERNEL); + gpt = kmalloc(ssz, GFP_KERNEL); if (!gpt) return NULL; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] Add aix lvm partitions support files
Hi Karel
On Mon, Apr 29, 2013 at 02:36:51PM +0200, Karel Zak wrote:
> On Mon, Apr 29, 2013 at 01:40:41PM +0200, Philippe De Muyter wrote:
> > > why not memset(pps_found, )? I also see magical constant 16
> >
> > Actually 16 is the maximum partition count allowed in a disk by linux,
> > or should it be 15 ? Is there already a constant for that ?
> > The AIX disk I tested with had only :) 11 partitions.
>
> I don't think it's correct to expect any hardcoded limit.
>
> The struct parsed_partitions->parts is allocated according to
> disk_max_parts() where the limit depends on number of minor numbers or
> it's DISK_MAX_PARTS (=256).
>
> There is no problem to create disk with many partitions:
>
> # modprobe scsi_debug dev_size_mb=300
> # (echo -e 'g\n'; for i in {1..100}; do echo -e "n\n\n\n+1M"; done; \
> echo -e 'w\nq\n') | fdisk /dev/sdb
>
> # lsblk -n /dev/sdb | wc -l
> 101
how are they named then ?
on my system (a 2.6.24 kernel which is the last one that support my
powerpc PReP machine because PReP support got removed with the merge
of /arch/ppc and /arch/powerpc :( ), I get :
root:~# ls -l /dev/sd[ab]*
brw-r- 1 root disk 8, 0 Apr 25 22:22 /dev/sda
brw-r- 1 root disk 8, 10 Apr 25 22:22 /dev/sda10
brw-r- 1 root disk 8, 11 Apr 25 22:22 /dev/sda11
brw-r- 1 root disk 8, 3 Apr 25 22:22 /dev/sda3
brw-r- 1 root disk 8, 4 Apr 25 22:22 /dev/sda4
brw-r- 1 root disk 8, 5 Apr 25 22:22 /dev/sda5
brw-r- 1 root disk 8, 6 Apr 25 22:22 /dev/sda6
brw-r- 1 root disk 8, 7 Apr 25 22:22 /dev/sda7
brw-r- 1 root disk 8, 8 Apr 25 22:22 /dev/sda8
brw-r- 1 root disk 8, 9 Apr 25 22:22 /dev/sda9
brw-r- 1 root disk 8, 16 Apr 25 22:22 /dev/sdb
brw-r- 1 root disk 8, 26 Apr 25 22:22 /dev/sdb10
brw-r- 1 root disk 8, 27 Apr 25 22:22 /dev/sdb11
brw-r- 1 root disk 8, 19 Apr 25 22:22 /dev/sdb3
brw-r- 1 root disk 8, 20 Apr 25 22:22 /dev/sdb4
brw-r- 1 root disk 8, 21 Apr 25 22:22 /dev/sdb5
brw-r- 1 root disk 8, 22 Apr 25 22:22 /dev/sdb6
brw-r- 1 root disk 8, 23 Apr 25 22:22 /dev/sdb7
brw-r- 1 root disk 8, 24 Apr 25 22:22 /dev/sdb8
brw-r- 1 root disk 8, 25 Apr 25 22:22 /dev/sdb9
root:~#
so sda is 8,0 and sdb is 8,16
and if, while discovering partitions of /dev/sda, I try to make a
partition 16 or higher, it is silently discarded by 'put_partition'.
Is that changed ?
Philippe
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] Add aix lvm partitions support files
On Mon, Apr 29, 2013 at 11:37:56AM +0200, Karel Zak wrote:
> On Thu, Apr 25, 2013 at 11:10:26PM +0200, Philippe De Muyter wrote:
Thanks for the interest and the quick reply.
> > +int aix_partition(struct parsed_partitions *state)
> > +{
> > + int ret = 0;
> > + Sector sect;
> > + unsigned char *d;
> > + u32 pp_bytes_size;
> > + u32 pp_blocks_size = 0;
> > + u32 vgda_sector = 0;
> > + u32 vgda_len = 0;
> > + int numlvs = 0;
> > + struct pvd *pvd;
> > + unsigned short pps_per_lv[16];
> > + unsigned short pps_found[16];
> > + unsigned char lv_is_contiguous[16];
> > + struct lvname *n = NULL;
> > +
> > + d = read_part_sector(state, 7, §);
> > + if (d) {
> > + struct lvm_rec *p = (struct lvm_rec *)d;
> > + u16 lvm_version = be16_to_cpu(p->version);
> > + char tmp[64];
> > +
> > + if (lvm_version == 1) {
> > + int pp_size_log2 = be16_to_cpu(p->pp_size);
> > +
> > + pp_bytes_size = 1 << pp_size_log2;
> > + pp_blocks_size = pp_bytes_size / 512;
> > + snprintf(tmp, sizeof(tmp), " AIX LVM header version %u
> > found\n", lvm_version);
>
> 'tmp' is nowhere used, maybe you want to use strlcat(state->pp_buf, tmp,
> PAGE_SIZE); too.
Oops, of course :)
>
> > + vgda_len = be32_to_cpu(p->vgda_len);
> > + vgda_sector = be32_to_cpu(p->vgda_psn[0]);
> > + } else {
> > + snprintf(tmp, sizeof(tmp), " unsupported AIX LVM
> > version %d found\n",
> > + lvm_version);
> > + strlcat(state->pp_buf, tmp, PAGE_SIZE);
> > + }
> > + put_dev_sector(sect);
> > + }
> > + if (vgda_sector && (d = read_part_sector(state, vgda_sector, §))) {
> > + struct vgda *p = (struct vgda *)d;
> > +
> > + numlvs = be16_to_cpu(p->numlvs);
> > + put_dev_sector(sect);
> > + }
> > + if (numlvs && (d = read_part_sector(state, vgda_sector + 1, §))) {
> > + struct lvd *p = (struct lvd *)d;
> > + int i;
> > +
> > + n = alloc_lvn(state, vgda_sector + vgda_len - 33);
> > + if (n) {
> > + int j = 0;
> > +
> > + memset(lv_is_contiguous, 0, 16);
> > + for (i = 0; i < 16; i += 1)
> > + pps_found[i] = 0;
>
> why not memset(pps_found, )? I also see magical constant 16
Actually 16 is the maximum partition count allowed in a disk by linux,
or should it be 15 ? Is there already a constant for that ?
The AIX disk I tested with had only :) 11 partitions.
> everywhere, maybe you can use sizeof() and ARRAY_SIZE().
Will do.
>
> > + for (i = 0; j < numlvs && i < 16; i += 1) {
> > + pps_per_lv[i] = be16_to_cpu(p[i].num_lps);
> > + if (pps_per_lv[i])
> > + j += 1;
> > + }
>
> hmm, what's wrong with j++ and i++, "j += 1" seems like old Python :-)
>
What's wrong with "j += 1" ?
I only use ++ for side effects; I personaly find "j += 1" more readable :)
But I should rename 'j' to be more explicit.
> > + while (i < 16)
> > + pps_per_lv[i++] = 0;
> > + }
> > + put_dev_sector(sect);
> > + }
> > + pvd = alloc_pvd(state, vgda_sector + 17);
> > + if (pvd) {
> > + int numpps = be16_to_cpu(pvd->pp_count);
> > + int psn_part1 = be32_to_cpu(pvd->psn_part1);
> > + int i;
> > + int cur_lv_ix = -1;
> > + int next_lp_ix = 1;
> > + int lp_ix;
> > +
> > + for (i = 0; i < numpps; i += 1) {
> > + struct ppe *p = pvd->ppe + i;
> > + int lv_ix;
> > +
> > + lp_ix = be16_to_cpu(p->lp_ix);
> > + if (!lp_ix) {
> > + next_lp_ix = 1;
> > + continue;
> > + }
> > + lv_ix = be16_to_cpu(p->lv_ix) - 1;
> > + pps_found[lv_ix] += 1;
>
> Would be better to be a little paranoid when you read the data from
> disk and check that lv_ix is
[PATCH 1/5] partitions/msdos.c: end-of-line whitespace and semicolon cleanup
Signed-off-by: Philippe De Muyter
Cc: Jens Axboe
---
block/partitions/msdos.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/block/partitions/msdos.c b/block/partitions/msdos.c
index 7681cd2..9bf19e6 100644
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -90,7 +90,7 @@ static int aix_magic_present(struct parsed_partitions *state,
unsigned char *p)
if (d[0] == '_' && d[1] == 'L' && d[2] == 'V' && d[3] == 'M')
ret = 1;
put_dev_sector(sect);
- };
+ }
return ret;
}
@@ -142,7 +142,7 @@ static void parse_extended(struct parsed_partitions *state,
return;
if (!msdos_magic_present(data + 510))
- goto done;
+ goto done;
p = (struct partition *) (data + 0x1be);
@@ -155,7 +155,7 @@ static void parse_extended(struct parsed_partitions *state,
* and OS/2 seems to use all four entries.
*/
- /*
+ /*
* First process the data partition(s)
*/
for (i=0; i<4; i++, p++) {
@@ -263,7 +263,7 @@ static void parse_solaris_x86(struct parsed_partitions
*state,
}
#if defined(CONFIG_BSD_DISKLABEL)
-/*
+/*
* Create devices for BSD partitions listed in a disklabel, under a
* dos-like partition. See parse_extended() for more information.
*/
@@ -294,7 +294,7 @@ static void parse_bsd(struct parsed_partitions *state,
if (state->next == state->limit)
break;
- if (p->p_fstype == BSD_FS_UNUSED)
+ if (p->p_fstype == BSD_FS_UNUSED)
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
@@ -441,7 +441,7 @@ static struct {
{NEW_SOLARIS_X86_PARTITION, parse_solaris_x86},
{0, NULL},
};
-
+
int msdos_partition(struct parsed_partitions *state)
{
sector_t sector_size = bdev_logical_block_size(state->bdev) / 512;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] Add aix lvm partitions support files
adding partitions/aix.h and partitions/aix.c
Partitions (called Logical Volumes in AIX) can be non-contiguous or
even split on more than one disk. Altough we detect such partitions,
we cannot describe them to the Linux partitions layer, so we simply
discard them and issue a diagnose message.
Signed-off-by: Philippe De Muyter
Cc: Jens Axboe
---
block/partitions/aix.c | 279
block/partitions/aix.h |1 +
2 files changed, 280 insertions(+), 0 deletions(-)
create mode 100644 block/partitions/aix.c
create mode 100644 block/partitions/aix.h
diff --git a/block/partitions/aix.c b/block/partitions/aix.c
new file mode 100644
index 000..c4c72ed
--- /dev/null
+++ b/block/partitions/aix.c
@@ -0,0 +1,279 @@
+/*
+ * fs/partitions/aix.c
+ *
+ * Copyright (C) 2012-2013 Philippe De Muyter
+ */
+
+#include "check.h"
+#include "aix.h"
+
+struct lvm_rec {
+ char lvm_id[4]; /* "_LVM" */
+ char reserved4[16];
+ __be32 lvmarea_len;
+ __be32 vgda_len;
+ __be32 vgda_psn[2];
+ char reserved36[10];
+ __be16 pp_size; /* log2(pp_size) */
+ char reserved46[12];
+ __be16 version;
+ };
+
+struct vgda {
+ __be32 secs;
+ __be32 usec;
+ char reserved8[16];
+ __be16 numlvs;
+ __be16 maxlvs;
+ __be16 pp_size;
+ __be16 numpvs;
+ __be16 total_vgdas;
+ __be16 vgda_size;
+ };
+
+struct lvd {
+ __be16 lv_ix;
+ __be16 res2;
+ __be16 res4;
+ __be16 maxsize;
+ __be16 lv_state;
+ __be16 mirror;
+ __be16 mirror_policy;
+ __be16 num_lps;
+ __be16 res10[8];
+ };
+
+struct lvname {
+ char name[64];
+ };
+
+struct ppe {
+ __be16 lv_ix;
+ unsigned short res2;
+ unsigned short res4;
+ __be16 lp_ix;
+ unsigned short res8[12];
+ };
+
+struct pvd {
+ char reserved0[16];
+ __be16 pp_count;
+ char reserved18[2];
+ __be32 psn_part1;
+ char reserved24[8];
+ struct ppe ppe[1016];
+ };
+
+/**
+ * last_lba(): return number of last logical block of device
+ * @bdev: block device
+ *
+ * Description: Returns last LBA value on success, 0 on error.
+ * This is stored (by sd and ide-geometry) in
+ * the part[0] entry for this disk, and is the number of
+ * physical sectors available on the disk.
+ */
+static u64 last_lba(struct block_device *bdev)
+{
+ if (!bdev || !bdev->bd_inode)
+ return 0;
+ return (bdev->bd_inode->i_size >> 9) - 1ULL;
+}
+
+/**
+ * read_lba(): Read bytes from disk, starting at given LBA
+ * @state
+ * @lba
+ * @buffer
+ * @count
+ *
+ * Description: Reads @count bytes from @state->bdev into @buffer.
+ * Returns number of bytes read on success, 0 on error.
+ */
+static size_t read_lba(struct parsed_partitions *state, u64 lba, u8 * buffer,
size_t count)
+{
+ size_t totalreadcount = 0;
+
+ if (!buffer || lba + count / 512 > last_lba(state->bdev))
+return 0;
+
+ while (count) {
+ int copied = 512;
+ Sector sect;
+ unsigned char *data = read_part_sector(state, lba++, §);
+ if (!data)
+ break;
+ if (copied > count)
+ copied = count;
+ memcpy(buffer, data, copied);
+ put_dev_sector(sect);
+ buffer += copied;
+ totalreadcount +=copied;
+ count -= copied;
+ }
+ return totalreadcount;
+}
+
+/**
+ * alloc_pvd(): reads physical volume descriptor
+ * @state
+ * @lba
+ *
+ * Description: Returns pvd on success, NULL on error.
+ * Allocates space for pvd and fill it with disk blocks at @lba
+ * Notes: remember to free pvd when you're done!
+ */
+static struct pvd *alloc_pvd(struct parsed_partitions *state, u32 lba)
+{
+ size_t count = sizeof(struct pvd);
+ struct pvd *p;
+
+ p = kzalloc(count, GFP_KERNEL);
+ if (!p)
+ return NULL;
+
+ if (read_lba(state, lba, (u8 *) p, count) < count) {
+ kfree(p);
+ return NULL;
+ }
+ return p;
+}
+
+/**
+ * alloc_lvn(): reads logical volume names
+ * @state
+ * @lba
+ *
+ * Description: Returns lvn on success, NULL on error.
+ * Allocates space for lvn and fill it with disk blocks at @lba
+ * Notes: remember to free lvn when you're done!
+ */
+static struct lvname *alloc_lvn(struct parsed_partitions *state, u32 lba)
+{
+ size_t count = sizeof(struct lvname) * 256;
+ struct lvname *p;
+
+ p = kzalloc(count, GFP_KERNEL);
+ if (!p)
+ return NULL;
+
+ if (read_lba(state, lba, (u8 *) p, count) < count) {
+ kfree(p);
+ return NULL;
+ }
+ return p;
+}
+
+int aix_partition(struct parsed_partitions *sta
[RFC PATCH 0/5] Add aix lvm partitions support
This patches serie implements a mapping from AIX LVM logical volumes to linux partitions, for AIX disks from versions AIX 3 & AIX 4, maybe later versions also, but this has not been tested. Because the LVM layer of AIX allows logical volumes to be made of separate so-called physical partitions which can be anywhere on the disk, and allows up to 256 logical volumes, while Linux allows only 16 partitions per disk, partitions which must be contiguous, only a subset of the AIX logical volumes found can be mappedi to linux partitions, but that's enough to make it usefull in real life. AIX partitions discovery has been grafted to the msdos partitions code, because AIX disks often contain an msdos partition table, and this grafting avoids removal of the AIX protection already included in msdos.c while avoiding code duplication. Comments welcome Philippe PS: a companion AIX JFS fs read-only driver will follow [PATCH 1/5] partitions/msdos.c: end-of-line whitespace and semicolon cleanup [PATCH 2/5] Add aix lvm partitions support files [PATCH 3/5] partitions/msdos: enumerate also AIX LVM partitions [PATCH 4/5] partitions/Makefile: compile aix.c if configured. [PATCH 5/5] partitions/Kconfig: add the AIX_PARTITION entry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] partitions/Kconfig: add the AIX_PARTITION entry
This is the final patch enabling a user to select AIX lvm partitions detection. Signed-off-by: Philippe De Muyter Cc: Jens Axboe --- block/partitions/Kconfig | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/block/partitions/Kconfig b/block/partitions/Kconfig index 75a54e1..4cebb2f 100644 --- a/block/partitions/Kconfig +++ b/block/partitions/Kconfig @@ -68,6 +68,17 @@ config ACORN_PARTITION_RISCIX of machines called RISCiX. If you say 'Y' here, Linux will be able to read disks partitioned under RISCiX. +config AIX_PARTITION + bool "AIX basic partition table support" if PARTITION_ADVANCED + help + Say Y here if you would like to be able to read the hard disk + partition table format used by IBM or Motorola PowerPC machines + running AIX. AIX actually uses a Logical Volume Manager, where + "logical volumes" can be spread across one or multiple disks, + but this driver works only for the simple case of partitions which + are contiguous. + Otherwise, say N. + config OSF_PARTITION bool "Alpha OSF partition support" if PARTITION_ADVANCED default y if ALPHA -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] partitions/msdos: enumerate also AIX LVM partitions
Graft AIX partitions enumeration in partitions/msdos.c
There is already a AIX disks detection logic in msdos.c. When an
AIX disk has been found, and if configured to, call the aix partitions
recognizer. This avoids removal of AIX disks protection from msdos.c,
avoids code duplication, and ensures that AIX partitions enumeration
is called before plain msdos partitions enumeration.
Signed-off-by: Philippe De Muyter
Cc: Jens Axboe
---
block/partitions/msdos.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/block/partitions/msdos.c b/block/partitions/msdos.c
index 9bf19e6..9123f25 100644
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -23,6 +23,7 @@
#include "check.h"
#include "msdos.h"
#include "efi.h"
+#include "aix.h"
/*
* Many architectures don't like unaligned accesses, while
@@ -462,8 +463,12 @@ int msdos_partition(struct parsed_partitions *state)
*/
if (aix_magic_present(state, data)) {
put_dev_sector(sect);
+#ifdef CONFIG_AIX_PARTITION
+ return aix_partition(state);
+#else
strlcat(state->pp_buf, " [AIX]", PAGE_SIZE);
return 0;
+#endif
}
if (!msdos_magic_present(data + 510)) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] partitions/Makefile: compile aix.c if configured.
Signed-off-by: Philippe De Muyter Cc: Jens Axboe --- block/partitions/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/block/partitions/Makefile b/block/partitions/Makefile index 03af8ea..2be4d7b 100644 --- a/block/partitions/Makefile +++ b/block/partitions/Makefile @@ -7,6 +7,7 @@ obj-$(CONFIG_BLOCK) := check.o obj-$(CONFIG_ACORN_PARTITION) += acorn.o obj-$(CONFIG_AMIGA_PARTITION) += amiga.o obj-$(CONFIG_ATARI_PARTITION) += atari.o +obj-$(CONFIG_AIX_PARTITION) += aix.o obj-$(CONFIG_MAC_PARTITION) += mac.o obj-$(CONFIG_LDM_PARTITION) += ldm.o obj-$(CONFIG_MSDOS_PARTITION) += msdos.o -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9-rc1 powerpc ptrace.c: 'brk.len' is used uninitialized
On Fri, Mar 08, 2013 at 10:03:34AM +1100, Michael Neuling wrote: > Michael Neuling wrote: > > diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c > index 245c1b6..8564515 100644 > --- a/arch/powerpc/kernel/ptrace.c > +++ b/arch/powerpc/kernel/ptrace.c > @@ -1428,6 +1428,7 @@ static long ppc_set_hwdebug(struct task_struct *child, > > brk.address = bp_info->addr & ~7UL; > brk.type = HW_BRK_TYPE_TRANSLATE; > + brk.len = 0; > if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ) > brk.type |= HW_BRK_TYPE_READ; > if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE) That's ok. Thanks Philippe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9-rc1 powerpc ptrace.c: 'brk.len' is used uninitialized
Hello Mikey, On Thu, Mar 07, 2013 at 10:14:30AM +1100, Michael Neuling wrote: > Philippe De Muyter wrote: > > > On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote: > > > > bisect tells me that since your commit > > > > 9422de3e953d0e60eb95f5430a9dd803eec1c6d7 > > > > "powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint > > > > registers", > > > > compiling linux fails with : > > > > > > > > cc1: warnings being treated as errors > > > > arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': > > > > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used > > > > uninitialized in this function > > > > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here > > > > > > > > could you look at that ? > > > > > > Sure. > > > > I use gcc-4.2.2, and my .config follows. > > I'm a bit lost. > > I don't have 4.2.2 (which is ancient BTW) and I can't hit this on > 4.3,4.5 or 4.6 with your config. It compiles fine. > > Also: > > > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used > > uninitialized in this function > > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here > > These line numbers make no sense at all WRT v3.9-rc1. brk.len is neither > declared or used in those lines: those were the line numbers just after your commit In 3.9-rc1 they are : cc1: warnings being treated as errors arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': arch/powerpc/kernel/ptrace.c:1479: warning: 'brk.len' is used uninitialized in this function arch/powerpc/kernel/ptrace.c:1381: note: 'brk.len' was declared here if (child->thread.hw_brk.address) return -ENOSPC; 1479: child->thread.hw_brk = brk; return 1; #endif /* !CONFIG_PPC_ADV_DEBUG_DVCS */ Philippe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9-rc1 powerpc ptrace.c: 'brk.len' is used uninitialized
On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote: > > bisect tells me that since your commit > > 9422de3e953d0e60eb95f5430a9dd803eec1c6d7 > > "powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint > > registers", > > compiling linux fails with : > > > > cc1: warnings being treated as errors > > arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': > > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used > > uninitialized in this function > > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here > > > > could you look at that ? > > Sure. I use gcc-4.2.2, and my .config follows. Philippe # # Automatically generated file; DO NOT EDIT. # Linux/powerpc 3.9.0-rc1 Kernel Configuration # # CONFIG_PPC64 is not set # # Processor support # CONFIG_PPC_BOOK3S_32=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y CONFIG_6xx=y CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set CONFIG_PPC_HAVE_PMU_SUPPORT=y # CONFIG_SMP is not set # CONFIG_PPC_DOORBELL is not set CONFIG_PPC32=y CONFIG_32BIT=y CONFIG_WORD_SIZE=32 # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set # CONFIG_ARCH_DMA_ADDR_T_64BIT is not set CONFIG_MMU=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set # CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK is not set CONFIG_NR_IRQS=512 CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_EPAPR_BOOT is not set # CONFIG_DEFAULT_UIMAGE is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_FHANDLE is not set # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set CONFIG_GENERIC_TIME_VSYSCALL_OLD=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set CONFIG_UIDGID_CONVERTED=y # CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EXPERT=y CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_EXCEPTION_TRACE=y # CONFIG_KALLSYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # # CONFIG_PERF_EVENTS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y # CONFIG_JUMP_LABEL is not set # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_ARCH_USE_BUILTIN_BSWAP=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_HAVE_VIRT_TO_BUS=y CONFIG_HAVE
3.9-rc1 powerpc ptrace.c: 'brk.len' is used uninitialized
Hello Michael, bisect tells me that since your commit 9422de3e953d0e60eb95f5430a9dd803eec1c6d7 "powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint registers", compiling linux fails with : cc1: warnings being treated as errors arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used uninitialized in this function arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here could you look at that ? Thanks Philippe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resent] dma: add the freescale-provided MultiChannel DMA driver
Hi Vinod, On Thu, Feb 21, 2013 at 03:22:33PM +0530, Vinod Koul wrote: > On Thu, Feb 21, 2013 at 09:29:47AM +0100, Philippe De Muyter wrote: > > > 2. If you are not using dmaengine APIs then drivers/dma/ is not a place > > > for you. > > > > What would be the place then for a multi-architecture dma driver. > > Freescale often > > reuses the same blocks for its m68k (coldfire), powerpc and arm (iMX) > > product > > lines. A dma driver with many similarities is already under the > > arch/powerpc > > subtree. I would like to avoid that, because it clearly hurts reusability. > So the question is will there be any more users of the driver other than the > ethernet one? If No then it should live with ethernet driver. > > DMAengine framework should be used where you have a system dma controller used > by different subsystems. I am not aware of any other user now, and my unique motivation is to get the ethernet driver into the kernel, for which this is a first step. As it is clearly a dma driver, it seemed to me fit to place it under drivers/dma, but I can understand that you disagree. I only wanted, by placing this driver under drivers/dma, to make it more visible, eventually getting some help to make it DMAengine enabled, and to avoid the need to move the files when the DMAengine interface would be added. So it is a chicken and egg question here :). Again, thanks for your answers. Stany and I are trying since Aug 2012 to get those drivers (MCD dma and MCD_FEC ethernet) in the kernel. Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resent] dma: add the freescale-provided MultiChannel DMA driver
Hi Vinod, On Wed, Feb 20, 2013 at 12:01:47PM +0530, Vinod Koul wrote: > On Mon, Feb 04, 2013 at 06:38:23PM +0100, Philippe De Muyter wrote: > > This patch adds the (cleaned-up) Freescale-provided MultiChannel DMA > > driver for ColdFire M54xx and MPC8220 processors. > > > > This driver is needed for the ethernet FEC driver of the ColdFire > > M547x and M548x processors. > > > > It is not dmaengine-enabled, but that's not needed for the above FEC driver. > > I have however installed it in the driver/dma tree as this IP block is not > > m68k-specific, but freescale-specific, and shared at least between powerpc > > and coldfire parts (possibly arm-parts as well). > > > > The installation in drivers/dma implies a small rule change in > > drivers/Makefile to enter drivers/dma on CONFIG_DMADEVICES instead > > of CONFIG_DMAENGINE. > BIG NAK Thanks for your answer. > 1. Please run Checkpath and reread Documentation/CodingStyle, specfically CH4. > Avoid the CamelCase I had run checkpatch when I made the patch, but CamelCase was not yet searched for at that time. I will look at that. > 2. If you are not using dmaengine APIs then drivers/dma/ is not a place for > you. What would be the place then for a multi-architecture dma driver. Freescale often reuses the same blocks for its m68k (coldfire), powerpc and arm (iMX) product lines. A dma driver with many similarities is already under the arch/powerpc subtree. I would like to avoid that, because it clearly hurts reusability. > 3. While glancing at the code, I dont see why you cant use dmaengine APIs? lack of need (the sole current user of this dma driver is a FEC ethernet driver which uses the current interface), time and expertise. but any help is welcome. > 4. lastly, am blown off by your own implementation of memcpy, WHY? Kernel is > smarter than you! I agree, but don't shoot the messenger. I am not the original author, this is freescale code. I only ensured that it compiles and works with current kernels, and suppressed many checkpatch warnings. Best regards Philippe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] block/partition/msdos: detect AIX formatted disks even without 55aa
AIX formatted disks do not always have the MSDOS 55aa signature.
This happens e.g. for unbootable AIX disks.
Up to now, such disks were not recognized as AIX disks, because of the
missing 55aa. Fix that by inverting the two tests. Let's first
check for the AIX magic strings, and only if that fails check for
the MSDOS magic word.
Signed-off-by: Philippe De Muyter
---
block/partitions/msdos.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
v2: add a comment to avoid accidental removal of the tests order
(suggested by Andreas Mohr )
diff --git a/block/partitions/msdos.c b/block/partitions/msdos.c
index 8752a5d..7681cd2 100644
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -455,14 +455,19 @@ int msdos_partition(struct parsed_partitions *state)
data = read_part_sector(state, 0, §);
if (!data)
return -1;
- if (!msdos_magic_present(data + 510)) {
+
+ /*
+* Note order! (some AIX disks, e.g. unbootable kind,
+* have no MSDOS 55aa)
+*/
+ if (aix_magic_present(state, data)) {
put_dev_sector(sect);
+ strlcat(state->pp_buf, " [AIX]", PAGE_SIZE);
return 0;
}
- if (aix_magic_present(state, data)) {
+ if (!msdos_magic_present(data + 510)) {
put_dev_sector(sect);
- strlcat(state->pp_buf, " [AIX]", PAGE_SIZE);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] block/partition/msdos: detect AIX formatted disks even without 55aa
AIX formatted disks do not always have the MSDOS 55aa signature.
This happens e.g. for unbootable AIX disks.
Up to now, such disks were not recognized as AIX disks, because of the
missing 55aa. Fix that by inverting the two tests. Let's first
check for the AIX magic strings, and only if that fails check for
the MSDOS magic word.
Signed-off-by: Philippe De Muyter
---
block/partitions/msdos.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/block/partitions/msdos.c b/block/partitions/msdos.c
index 8752a5d..4b31ed7 100644
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -455,14 +455,15 @@ int msdos_partition(struct parsed_partitions *state)
data = read_part_sector(state, 0, §);
if (!data)
return -1;
- if (!msdos_magic_present(data + 510)) {
+
+ if (aix_magic_present(state, data)) {
put_dev_sector(sect);
+ strlcat(state->pp_buf, " [AIX]", PAGE_SIZE);
return 0;
}
- if (aix_magic_present(state, data)) {
+ if (!msdos_magic_present(data + 510)) {
put_dev_sector(sect);
- strlcat(state->pp_buf, " [AIX]", PAGE_SIZE);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
Hi Greg,
On Tue, Oct 16, 2012 at 04:39:05PM +1000, Greg Ungerer wrote:
> Hi Philippe,
>
> On 09/10/12 19:07, Philippe De Muyter wrote:
>> [CCing lkml, linux-ppc, netdev, linux-m68k]
>>
>> Hello kernel sources architects
>>
>> I have a working driver for the m54xx FEC ethernet driver that I
>> would like to integrate in the kernel tree. Problems are that
>> - this driver needs an associated DMA driver (provided by FreeScale)
>> wich is not dma-engine enabled
>> - they're are already many fec drivers in the kernel tree, and
>> at least one, fec_mpc52xx.c, seems to be very similar (information
>> below), to the one for the mcf54xx, except it uses a differently
>> named associated DMA driver (BestComm/SmartDma/SDMA) which is also
>> not dma-engine enabled, and even kept hidden in /arch/powerpc where
>> it is inaccessible when compiling for m68k. The underlying DMA part
>> from Freescale however seems similar to the one used in the
>> m54xx. (again, see information below)
>>
>> So, now I am lost, what should I do ?
>>
>> The current state of my patches
>> [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html]
>> is pushing the freescale provided MCD_DMA dma driver to /drivers/dma,
>> without adding the dma-engine compatibility layer, and adding the specific
>> fec_m54xx ethernet driver to /drivers/net/ethernet/freescale
>
> Do you get any responses?
> I didn't see any...
No, and none also about my simpler patch moving arch/powerpc/sysdev/bestcomm
to drivers/dma/bestcomm (except a private and useful one telling me how to
set '-M' option as default for 'git format-patch'), but at least this simpler
patch seems to be in a wait bucket at
http://patchwork.ozlabs.org/project/linuxppc-dev/list/.
Regards
Philippe
PS: -M as default for 'git format-patch':
put
[diff]
renames = true
in .git/config
>
> Regards
> Greg
>
>
>
>> On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote:
>>> Hi Philippe,
>>>
>>> On 05/10/12 01:03, Philippe De Muyter wrote:
>>>> On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote:
>>>>> On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote:
>>>>>>
>>>>>> My biggest concern is the amount of MCD/DMA support code. And it is
>>>>>> all done quite differently to everything else in the kernel. We may
>>>>>> get a bit of push back from kernel folk who look after DMA.
>>>>>
>>>>> Actually, there is already a similar code in
>>>>> arch/powerpc/sysdev/bestcomm
>>>>> (also from freescale, maybe an identical part, but I did not find any
>>>>> usable doc), but the powerpc folks kept that hidden in the arch/powerpc
>>>>> tree, instead of installing it in drivers/dma.
>>>>
>>>> The MCD DMA or DMA FEC code from freescale has a comment implying that
>>>> this
>>>> was first used in the MPC8220 part. And Montavista has a MPC8220 port,
>>>> but
>>>> I did not find it, so I do not know where they installed the MCD DMA
>>>> driver.
>>>
>>> Ok, looks like there is a bit a variance in all this.
>>
>> I also began to read the mpc5200 user's guide parts about the fec and
>> BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name)
>> and they look very similar, but not identical, to their m54xx
>> counterparts.
>>
>> It seems possible to make the fec_mpc52xx.c driver work for the m54xx
>> but that needs at least:
>> - moving some files or part of them from /arch/powerpc/sysdev and
>>/arch/powerpc/include/asm to /drivers/dma and /include/linux,
>> - renaming the fec_mpc52xx files to a more sensible name,
>> - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h,
>> - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA
>>in mcf_52xx.c.
>>
>> An additional problem is that the freescale docs for powerpcs and for
>> coldfires do not use the same mnemonics for the same registers.
>>
>> e.g. FEC registers
>> offset MPC5200 MCF5484
>> == === ===
>> 000 FEC_ID n/a
>> 004 IEVENT EIR
>> 008 IMASK EIMR
>> 010 R_DES_ACTIVEn/a
>> 014 X_DES_ACTIVEn/a
>> 024 ECNTRL ECR
>> 040 MII_DATAMDATA
>> 044 MII_SPEED MSCR
&
[PATCH v2] powerpc,dma: move bestcomm driver from arch/powerpc/sysdev to drivers/dma
The bestcomm dma hardware, and some of its users like the FEC ethernet
component, is used in different FreeScale parts, including non-powerpc
parts like the ColdFire MCF547x & MCF548x families. Don't keep the
driver hidden in arch/powerpc where it is inaccessible for other arches.
.c files are moved to arch/drivers/dma/bestcomm, while
.h files are moved to include/linux/fsl/bestcomm. Makefiles, Kconfigs
and #include directives are updated for the new file locations.
Tested by recompiling for MPC5200 with all bestcomm users enabled.
Signed-off-by: Philippe De Muyter
---
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |6 +++---
arch/powerpc/platforms/Kconfig |2 --
arch/powerpc/sysdev/Makefile |1 -
drivers/Makefile |2 +-
drivers/ata/pata_mpc52xx.c |6 +++---
drivers/dma/Kconfig|2 ++
drivers/dma/Makefile |1 +
.../sysdev => drivers/dma}/bestcomm/Kconfig|0
.../sysdev => drivers/dma}/bestcomm/Makefile |0
.../powerpc/sysdev => drivers/dma}/bestcomm/ata.c |6 +++---
.../dma}/bestcomm/bcom_ata_task.c |0
.../dma}/bestcomm/bcom_fec_rx_task.c |0
.../dma}/bestcomm/bcom_fec_tx_task.c |0
.../dma}/bestcomm/bcom_gen_bd_rx_task.c|0
.../dma}/bestcomm/bcom_gen_bd_tx_task.c|0
.../sysdev => drivers/dma}/bestcomm/bestcomm.c |6 +++---
.../powerpc/sysdev => drivers/dma}/bestcomm/fec.c |6 +++---
.../sysdev => drivers/dma}/bestcomm/gen_bd.c |6 +++---
.../powerpc/sysdev => drivers/dma}/bestcomm/sram.c |2 +-
drivers/net/ethernet/freescale/fec_mpc52xx.c |4 ++--
.../sysdev => include/linux/fsl}/bestcomm/ata.h|0
.../linux/fsl}/bestcomm/bestcomm.h |0
.../linux/fsl}/bestcomm/bestcomm_priv.h|0
.../sysdev => include/linux/fsl}/bestcomm/fec.h|0
.../sysdev => include/linux/fsl}/bestcomm/gen_bd.h |0
.../sysdev => include/linux/fsl}/bestcomm/sram.h |0
sound/soc/fsl/mpc5200_dma.c|4 ++--
27 files changed, 27 insertions(+), 27 deletions(-)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/Kconfig (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/Makefile (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/ata.c (97%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_ata_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_fec_rx_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_fec_tx_task.c (100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_gen_bd_rx_task.c
(100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bcom_gen_bd_tx_task.c
(100%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/bestcomm.c (99%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/fec.c (98%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/gen_bd.c (98%)
rename {arch/powerpc/sysdev => drivers/dma}/bestcomm/sram.c (99%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/ata.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/bestcomm.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/bestcomm_priv.h
(100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/fec.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/gen_bd.h (100%)
rename {arch/powerpc/sysdev => include/linux/fsl}/bestcomm/sram.h (100%)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index 2351f9e..089e665 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -20,9 +20,9 @@
#include
#include
-#include
-#include
-#include
+#include
+#include
+#include
MODULE_AUTHOR("Grant Likely ");
MODULE_DESCRIPTION("MPC5200 LocalPlus FIFO device driver");
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index e7a896a..405f763 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -351,8 +351,6 @@ config OF_RTC
Uses information from the OF or flattened device tree to instantiate
platform devices for direct mapped RTC chips like the DS1742 or
DS1743.
-source "arch/powerpc/sysdev/bestcomm/Kconfig"
-
config SIMPLE_GPIO
bool "Support for simple, memory-mapped GPIO controllers"
depends on PPC
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index a57600b..3884776 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -26,7 +26,6 @@ obj-$(CONFIG_SIMPLE_GPIO) +
[m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
[CCing lkml, linux-ppc, netdev, linux-m68k] Hello kernel sources architects I have a working driver for the m54xx FEC ethernet driver that I would like to integrate in the kernel tree. Problems are that - this driver needs an associated DMA driver (provided by FreeScale) wich is not dma-engine enabled - they're are already many fec drivers in the kernel tree, and at least one, fec_mpc52xx.c, seems to be very similar (information below), to the one for the mcf54xx, except it uses a differently named associated DMA driver (BestComm/SmartDma/SDMA) which is also not dma-engine enabled, and even kept hidden in /arch/powerpc where it is inaccessible when compiling for m68k. The underlying DMA part from Freescale however seems similar to the one used in the m54xx. (again, see information below) So, now I am lost, what should I do ? The current state of my patches [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html] is pushing the freescale provided MCD_DMA dma driver to /drivers/dma, without adding the dma-engine compatibility layer, and adding the specific fec_m54xx ethernet driver to /drivers/net/ethernet/freescale Best regards Philippe On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote: > Hi Philippe, > > On 05/10/12 01:03, Philippe De Muyter wrote: >> On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote: >>> On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote: >>>> >>>> My biggest concern is the amount of MCD/DMA support code. And it is >>>> all done quite differently to everything else in the kernel. We may >>>> get a bit of push back from kernel folk who look after DMA. >>> >>> Actually, there is already a similar code in arch/powerpc/sysdev/bestcomm >>> (also from freescale, maybe an identical part, but I did not find any >>> usable doc), but the powerpc folks kept that hidden in the arch/powerpc >>> tree, instead of installing it in drivers/dma. >> >> The MCD DMA or DMA FEC code from freescale has a comment implying that >> this >> was first used in the MPC8220 part. And Montavista has a MPC8220 port, >> but >> I did not find it, so I do not know where they installed the MCD DMA >> driver. > > Ok, looks like there is a bit a variance in all this. I also began to read the mpc5200 user's guide parts about the fec and BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name) and they look very similar, but not identical, to their m54xx counterparts. It seems possible to make the fec_mpc52xx.c driver work for the m54xx but that needs at least: - moving some files or part of them from /arch/powerpc/sysdev and /arch/powerpc/include/asm to /drivers/dma and /include/linux, - renaming the fec_mpc52xx files to a more sensible name, - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h, - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA in mcf_52xx.c. An additional problem is that the freescale docs for powerpcs and for coldfires do not use the same mnemonics for the same registers. e.g. FEC registers offset MPC5200 MCF5484 == === === 000 FEC_ID n/a 004 IEVENT EIR 008 IMASK EIMR 010 R_DES_ACTIVEn/a 014 X_DES_ACTIVEn/a 024 ECNTRL ECR 040 MII_DATAMDATA 044 MII_SPEED MSCR 064 MIB_CONTROL MIBC 084 R_CNTRL RCR 088 R_HASH RHR 0C4 X_CNTRL TCR 0E4 PADDR1 PALR 0E8 PADDR2 PAHR 0EC OP_PAUSEOPD 118 IADDR1 IAUR 11C IADDR1 IALR 120 GADDR1 GAUR 124 GADDR2 GALR 144 X_WMRK FECTFWR 184 RFIFO_DATA FECRFDR 188 RFIFO_STATUSFECRFSR 18C RFIFO_CONTROL FECRFCR 190 RFIFO_LRF_PTR FECRLRFP 194 RFIFO_LWF_PTR FECRLWFP 198 RFIFO_ALARM FECRFAR 19C RFIFO_RDPTR FECRFRP 1A0 RFIFO_WRPTR FECRFWP 1A4 TFIFO_DATA FECTFDR 1A8 TFIFO_STATUSFECTFSR 1AC TFIFO_CONTROL FECTFCR 1B0 TFIFO_LRF_PTR FECTLRFP 1B4 TFIFO_LWF_PTR FECTLWFP 1B8 TFIFO_ALARM FECTFAR 1BC TFIFO_RDPTR FECTFRP 1C0 TFIFO_WRPTR FECTFWP 1C4 RESET_CNTRL FECFRST 1C8 XMIT_FSMFECCTCWR > Probably the best thing to do is post the patches on the linux kernel > mailing list then, asking for direction on a dma driver. > > I have no problem with it going into the arch/m68k area.
Re: [PATCH v2] checkpatch: Suggest using min_t or max_t
On Wed, Sep 5, 2012 at 7:07 PM, Joe Perches wrote:
> On Wed, 2012-09-05 at 13:21 +0200, Philippe De Muyter wrote:
>> > v2: Make $match_balanced_parentheses work in perl 5.8
>>
>> Has this been applied ?
>>
>> v3.3 version of checkpatch.pl works for me, but v3.4, v3.5 & v3.6rc2 say:
>> Nested quantifiers in regex; marked by <-- HERE in m/(\((?:[^\(\)]++
>> <-- HERE |(?-1))*\))/ at scripts/checkpatch.pl line 340.
>>
>> and my perl is :
>>
>> perl --version
>>
>> This is perl, v5.8.8 built for i586-linux-thread-multi
>
> The current version of checkpatch skips this
> check when the perl version is less than 5.10.0
>
>
> commit d7c76ba7e58bc3ca674f20759c686535db484749
> Author: Joe Perches
> Date: Tue Jan 10 15:09:58 2012 -0800
>
> checkpatch: improve memset and min/max with cast checking
>
> Improve the checking of arguments to memset and min/max tests.
>
> Move the checking of min/max to statement blocks instead of single line.
> Change $Constant to allow any case type 0x initiator and trailing ul
> specifier. Add $FuncArg type as any function argument with or without a
> cast. Print the whole statement when showing memset or min/max messages.
> Improve the memset with 0 as 3rd argument error message.
>
> There are still weaknesses in the $FuncArg and $Constant code as arbitrary
> parentheses and negative signs are not generically supported.
>
> []
> # Using $balanced_parens, $LvalOrFunc, or $FuncArg
> # requires at least perl version v5.10.0
> # Any use must be runtime checked with $^V
> []
> # typecasts on min/max could be min_t/max_t
> if ($^V && $^V ge 5.10.0 &&
> defined $stat &&
> $stat =~
> /^\+(?:.*?)\b(min|max)\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\)/) {
>
>
I know nothing about perl, and when I read 3.6rc2's checkpatch.pl it
seems to me that every usage of $balanced_parens, $LvalOrFunc, or
$FuncArg is protected by a test for v5.10.0, but line 340, which perl
complains about, is not a use, but merely a definition. Should the
definition not be protected too ?
Philippe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] checkpatch: Suggest using min_t or max_t
On 5/27/11, Joe Perches wrote: > A common issue with min() or max() is using a cast on > one or both of the arguments when using min_t/max_t could > be better. > > Add cast detection to uses of min/max and suggest an > appropriate use of min_t or max_t instead. > > Caveat: This only works for min() or max() on a single line. > It does not find min() or max() split across multiple lines. > > This does find: > min((u32)foo, bar); > But it does not find: > max((unsigned long)foo, > bar); > > Suggested-by: Andrew Morton > Signed-off-by: Joe Perches > --- > > v2: Make $match_balanced_parentheses work in perl 5.8 Has this been applied ? v3.3 version of checkpatch.pl works for me, but v3.4, v3.5 & v3.6rc2 say: Nested quantifiers in regex; marked by <-- HERE in m/(\((?:[^\(\)]++ <-- HERE |(?-1))*\))/ at scripts/checkpatch.pl line 340. and my perl is : perl --version This is perl, v5.8.8 built for i586-linux-thread-multi Philippe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Add support to M54xx DMA FEC Driver
Hi Stany & Greg Seeing that I was not the only one wanting to have the m54xx fec dma driver merged in, and hoping to compare Stany's version to mine, I have rebased (step by step) my patch from v2.38 to v3.6rc2. The driver still works and perhaps even better due to some fixes in other m68k area. Unfortunately I have not being able to compare it yet fully with Stany's version because Stany's patch 2/2 did not apply (using `git am') to v3.5 or v3.6rc2. I have checked my patch using a recent version of checkpatch.pl (not the v3.5 version, because v3.5 version of checkpatch.pl fails with : Nested quantifiers in regex; marked by <-- HERE in m/(\((?:[^\(\)]++ <-- HERE |( ?-1))*\))/ at scripts/checkpatch.pl line 340.)) and I am now at : 464 WARNING: line over 80 characters 90 WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt Many "volatile" warnings are about such definitions : #define FEC_FECFRST(x) (*(volatile unsigned int *)(x + 0x1C4)) which are afterwards used with + FEC_FECFRST(base_addr) |= FEC_SW_RST; + FEC_FECFRST(base_addr) &= ~FEC_SW_RST; + FEC_FECFRST(base_addr) |= FEC_SW_RST; + FEC_FECFRST(base_addr) &= ~FEC_SW_RST; + FEC_FECFRST(base_addr) |= FEC_SW_RST | FEC_RST_CTL; + FEC_FECFRST(base_addr) &= ~FEC_SW_RST; Any advice about those ones ? while many "80 characters" ones are about : #4014: FILE: arch/m68k/platform/coldfire/MCD_tasks.c:2406: + 0x600b, /* 0098(:1560): DRD2A: EU0=0 EU1=0 EU2=0 EU3=11 EXT ini t=0 WS=0 RS=0 */ I would like to keep those lines intact because the comment seems to actually be the assembler source of the hex value at left, which seems to be a microcode, and it makes sense to me to keep that on one line. What do you think about that ? I did not include the current status of the patch because of its size (I did not separate the dma part of the ethernet driver part because the dma part is useless without the ethernet driver, and linking the ethernet driver cannot succeed without the dma part), but if you ask, I'll send it privately. Best regards Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Add support to broadcom 5222 PHY
On Thu, Aug 23, 2012 at 05:21:23PM +0200, Stany MARCEL wrote:
> On Thu, Aug 23, 2012 at 12:47 PM, Geert Uytterhoeven
> wrote:
> > On Tue, Aug 21, 2012 at 2:18 PM, Stany MARCEL
> > wrote:
> >> Signed-off-by: Stany MARCEL
> >> ---
> >>
> >> This driver is an adaption of the one given by freescale for kernel
> >> 2.6.25.
> >>
> >> Tested with kernel 3.4.8 with arch/m68k backported from linux-m68k head
> >> 2 FEC configured with shared phy
> >>
> >> drivers/net/phy/Kconfig|7 +-
> >> drivers/net/phy/Makefile |1 +
> >> drivers/net/phy/broadcom522x.c | 171
> >>
> >
> > This patch and "[PATCH 3/3] Add support to M54xx DMA FEC Driver" need to go
> > through the netdev tree, or collect acks there.
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
>
> Hello Geert,
>
> Please, what is the good process to follow as patch 3 depends on patch 1 ?
Actually, IMHO patch 3 does not depend on patch 1, and I even think that
patch 1 is not needed, except to get a message with "BCM5222" instead
of "Generic PHY" in the kernel log.
AFAIK the phy interface is standardized.
Philippe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
POWERPC : What's "SPE used in kernel" ?
Dear list, I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540 specific gcc. I then got thousands of "SPE used in kernel" messages. Looking at the sources I ifdeffed out the printk call in KernelSPE, and I now have a silent kernel, that seems to work fine. Is there something wrong in my setting and should I look further to debug this problem or is this perfectly normal ? I wonder why a kernel configured for E500 using a E500-specific gcc triggers this message. Is it invalid to use SPE instructions in the kernel ? Philippe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hint needed : how to debug sempahore's problem
Hi all, Can someone give me some hint or link for the following question : I have several processes blocked in 'D' state, and I surmise they are waiting for a semaphore (in the `down' routine). How is it possible : - to verify the processes are really blocked on a semaphore, - to see which semaphore they are waiting on, - to find out which process/driver/whatever holds those semaphores. If that matters, I work on a m68k board. Thanks in advance Philippe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uclinux patches submission and author credit
Hi Greg, On Tue, Aug 07, 2007 at 04:20:54PM +1000, Greg Ungerer wrote: > Currently if I submit a patch that was sent to me with a > Signed-off-by line I just add mine underneath it and send. > If the patch didn't come with a Signed-off-by then I put the > original author in a "From" line at the top of the submission. > Looks like I should always add a "From" line. That's fine. Thanks. I didn't know either about the From: field. Philippe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
uclinux patches submission and author credit
Hi Andrew and Greg, Currently, all the patches that are submitted via Greg are marked as authored by Greg. Actually, the author is named in the first Signed-off-by line (often Greg himself, sometimes someone other). Would it be possible to fix the patch submission scheme so that the real author is credited ? Thanks in advance Philippe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs : mark nibblemap const
Hi all
Mark nibblemap const
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
diff -r 6c0a10cc415a fs/affs/bitmap.c
--- a/fs/affs/bitmap.c Thu Jul 5 16:10:16 2007 -0700
+++ b/fs/affs/bitmap.c Fri Jul 13 12:21:14 2007 +0200
@@ -11,7 +11,7 @@
/* This is, of course, shamelessly stolen from fs/minix */
-static int nibblemap[] = { 0,1,1,2,1,2,2,3,1,2,2,3,2,3,3,4 };
+static const int nibblemap[] = { 0,1,1,2,1,2,2,3,1,2,2,3,2,3,3,4 };
static u32
affs_count_free_bits(u32 blocksize, const void *data)
diff -r 6c0a10cc415a fs/ext2/balloc.c
--- a/fs/ext2/balloc.c Thu Jul 5 16:10:16 2007 -0700
+++ b/fs/ext2/balloc.c Fri Jul 13 12:21:14 2007 +0200
@@ -522,7 +522,7 @@ io_error:
#ifdef EXT2FS_DEBUG
-static int nibblemap[] = {4, 3, 3, 2, 3, 2, 2, 1, 3, 2, 2, 1, 2, 1, 1, 0};
+static const int nibblemap[] = {4, 3, 3, 2, 3, 2, 2, 1, 3, 2, 2, 1, 2, 1, 1,
0};
unsigned long ext2_count_free (struct buffer_head * map, unsigned int numchars)
{
diff -r 6c0a10cc415a fs/ext3/bitmap.c
--- a/fs/ext3/bitmap.c Thu Jul 5 16:10:16 2007 -0700
+++ b/fs/ext3/bitmap.c Fri Jul 13 12:21:14 2007 +0200
@@ -13,7 +13,7 @@
#ifdef EXT3FS_DEBUG
-static int nibblemap[] = {4, 3, 3, 2, 3, 2, 2, 1, 3, 2, 2, 1, 2, 1, 1, 0};
+static const int nibblemap[] = {4, 3, 3, 2, 3, 2, 2, 1, 3, 2, 2, 1, 2, 1, 1,
0};
unsigned long ext3_count_free (struct buffer_head * map, unsigned int numchars)
{
diff -r 6c0a10cc415a fs/ext4/bitmap.c
--- a/fs/ext4/bitmap.c Thu Jul 5 16:10:16 2007 -0700
+++ b/fs/ext4/bitmap.c Fri Jul 13 12:21:14 2007 +0200
@@ -13,7 +13,7 @@
#ifdef EXT4FS_DEBUG
-static int nibblemap[] = {4, 3, 3, 2, 3, 2, 2, 1, 3, 2, 2, 1, 2, 1, 1, 0};
+static const int nibblemap[] = {4, 3, 3, 2, 3, 2, 2, 1, 3, 2, 2, 1, 2, 1, 1,
0};
unsigned long ext4_count_free (struct buffer_head * map, unsigned int numchars)
{
diff -r 6c0a10cc415a fs/minix/bitmap.c
--- a/fs/minix/bitmap.c Thu Jul 5 16:10:16 2007 -0700
+++ b/fs/minix/bitmap.c Fri Jul 13 12:21:14 2007 +0200
@@ -17,7 +17,7 @@
#include
#include
-static int nibblemap[] = { 4,3,3,2,3,2,2,1,3,2,2,1,2,1,1,0 };
+static const int nibblemap[] = { 4,3,3,2,3,2,2,1,3,2,2,1,2,1,1,0 };
static unsigned long count_free(struct buffer_head *map[], unsigned numblocks,
__u32 numbits)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] block : make partitions_op & diskstats_op const
Hi all,
Make partitions_op & diskstats_op const
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
diff -r 6c0a10cc415a block/genhd.c
--- a/block/genhd.c Thu Jul 5 16:10:16 2007 -0700
+++ b/block/genhd.c Fri Jul 6 15:57:07 2007 +0200
@@ -328,7 +328,7 @@ static int show_partition(struct seq_fil
return 0;
}
-struct seq_operations partitions_op = {
+const struct seq_operations partitions_op = {
.start =part_start,
.next = part_next,
.stop = part_stop,
@@ -689,7 +689,7 @@ static int diskstats_show(struct seq_fil
return 0;
}
-struct seq_operations diskstats_op = {
+const struct seq_operations diskstats_op = {
.start = diskstats_start,
.next = diskstats_next,
.stop = diskstats_stop,
diff -r 6c0a10cc415a fs/proc/proc_misc.c
--- a/fs/proc/proc_misc.c Thu Jul 5 16:10:16 2007 -0700
+++ b/fs/proc/proc_misc.c Fri Jul 6 15:57:07 2007 +0200
@@ -357,7 +357,7 @@ static int stram_read_proc(char *page, c
#endif
#ifdef CONFIG_BLOCK
-extern struct seq_operations partitions_op;
+extern const struct seq_operations partitions_op;
static int partitions_open(struct inode *inode, struct file *file)
{
return seq_open(file, &partitions_op);
@@ -369,7 +369,7 @@ static const struct file_operations proc
.release= seq_release,
};
-extern struct seq_operations diskstats_op;
+extern const struct seq_operations diskstats_op;
static int diskstats_open(struct inode *inode, struct file *file)
{
return seq_open(file, &diskstats_op);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net : make netlink_seq_ops const
On Fri, Jul 06, 2007 at 02:52:11PM +0200, Patrick McHardy wrote: > [please send networking patches to netdev] > > Philippe De Muyter wrote: > > Hi all, > > > > Make netlink_seq_ops const > > > Might make more sense to do a big patch for all occurences of this > in net/: > > # grep "^static struct seq_operations" -r net/ | wc -l > 76 OK Philippe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net : make netlink_seq_ops const
Hi all,
Make netlink_seq_ops const
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
diff -r 6c0a10cc415a net/netlink/af_netlink.c
--- a/net/netlink/af_netlink.c Thu Jul 5 16:10:16 2007 -0700
+++ b/net/netlink/af_netlink.c Fri Jul 6 14:43:30 2007 +0200
@@ -1713,7 +1713,7 @@ static int netlink_seq_show(struct seq_f
return 0;
}
-static struct seq_operations netlink_seq_ops = {
+static const struct seq_operations netlink_seq_ops = {
.start = netlink_seq_start,
.next = netlink_seq_next,
.stop = netlink_seq_stop,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] m68knommu : make cpuinfo_op const
Hi all,
Make m68knommu cpuinfo_op const.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
diff -r 6c0a10cc415a arch/m68knommu/kernel/setup.c
--- a/arch/m68knommu/kernel/setup.c Thu Jul 5 16:10:16 2007 -0700
+++ b/arch/m68knommu/kernel/setup.c Fri Jul 6 13:37:57 2007 +0200
@@ -313,7 +313,7 @@ static void c_stop(struct seq_file *m, v
{
}
-struct seq_operations cpuinfo_op = {
+const struct seq_operations cpuinfo_op = {
.start = c_start,
.next = c_next,
.stop = c_stop,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net : make ip_tos2prio const
Hi all,
Make ip_tos2prio `const'.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
diff -r 6c0a10cc415a include/net/route.h
--- a/include/net/route.h Thu Jul 5 16:10:16 2007 -0700
+++ b/include/net/route.h Fri Jul 6 13:23:35 2007 +0200
@@ -136,7 +136,7 @@ static inline void ip_rt_put(struct rtab
#define IPTOS_RT_MASK (IPTOS_TOS_MASK & ~3)
-extern __u8 ip_tos2prio[16];
+extern const __u8 ip_tos2prio[16];
static inline char rt_tos2priority(u8 tos)
{
diff -r 6c0a10cc415a net/ipv4/route.c
--- a/net/ipv4/route.c Thu Jul 5 16:10:16 2007 -0700
+++ b/net/ipv4/route.c Fri Jul 6 13:23:35 2007 +0200
@@ -168,7 +168,7 @@ static struct dst_ops ipv4_dst_ops = {
#define ECN_OR_COST(class) TC_PRIO_##class
-__u8 ip_tos2prio[16] = {
+const __u8 ip_tos2prio[16] = {
TC_PRIO_BESTEFFORT,
ECN_OR_COST(FILLER),
TC_PRIO_BESTEFFORT,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ppp : white space cleanup
Hi all,
This removes useless spaces at begin of lines
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
diff -r 6c0a10cc415a drivers/net/ppp_async.c
--- a/drivers/net/ppp_async.c Thu Jul 5 16:10:16 2007 -0700
+++ b/drivers/net/ppp_async.c Fri Jul 6 12:15:38 2007 +0200
@@ -887,15 +887,15 @@ ppp_async_input(struct asyncppp *ap, con
skb = dev_alloc_skb(ap->mru + PPP_HDRLEN + 2);
if (skb == 0)
goto nomem;
- ap->rpkt = skb;
- }
- if (skb->len == 0) {
- /* Try to get the payload 4-byte aligned.
-* This should match the
-* PPP_ALLSTATIONS/PPP_UI/compressed tests in
-* process_input_packet, but we do not have
-* enough chars here to test buf[1] and buf[2].
-*/
+ ap->rpkt = skb;
+ }
+ if (skb->len == 0) {
+ /* Try to get the payload 4-byte aligned.
+* This should match the
+* PPP_ALLSTATIONS/PPP_UI/compressed tests in
+* process_input_packet, but we do not have
+* enough chars here to test buf[1] and buf[2].
+*/
if (buf[0] != PPP_ALLSTATIONS)
skb_reserve(skb, 2 + (buf[0] & 1));
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtd : add FUJITSU MBM29F800BA and ST M29F800AB descriptions
On Thu, Jul 05, 2007 at 01:23:16PM -0400, David Woodhouse wrote: > On Thu, 2007-07-05 at 17:05 +0200, Philippe De Muyter wrote: > > Add descriptions for Fujitsu MBM29F800BA and ST M29F800AB flash chips. > > Those chips are compatible (except for the ids) with the AMD > > AM29F800BB. > > Aren't these CFI-compliant? No Philippe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mtd : add FUJITSU MBM29F800BA and ST M29F800AB descriptions
Hi all,
Add descriptions for Fujitsu MBM29F800BA and ST M29F800AB flash chips.
Those chips are compatible (except for the ids) with the AMD AM29F800BB.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
diff -r d857b8fa1d27 drivers/mtd/chips/jedec_probe.c
--- a/drivers/mtd/chips/jedec_probe.c Sun Jun 24 12:08:53 2007 -0700
+++ b/drivers/mtd/chips/jedec_probe.c Thu Jul 5 16:46:25 2007 +0200
@@ -70,6 +70,7 @@
/* Fujitsu */
#define MBM29F040C 0x00A4
+#define MBM29F800BA0x2258
#define MBM29LV650UE 0x22D7
#define MBM29LV320TE 0x22F6
#define MBM29LV320BE 0x22F9
@@ -129,6 +130,7 @@
#define LH28F640BF 0x00b0
/* ST - www.st.com */
+#define M29F800AB 0x0058
#define M29W800DT 0x00D7
#define M29W800DB 0x005B
#define M29W160DT 0x22C4
@@ -646,6 +648,23 @@ static const struct amd_flash_info jedec
}
}, {
.mfr_id = MANUFACTURER_FUJITSU,
+ .dev_id = MBM29F800BA,
+ .name = "Fujitsu MBM29F800BA",
+ .uaddr = {
+ [0] = MTD_UADDR_0x0AAA_0x0555, /* x8 */
+ [1] = MTD_UADDR_0x0555_0x02AA, /* x16 */
+ },
+ .DevSize= SIZE_1MiB,
+ .CmdSet = P_ID_AMD_STD,
+ .NumEraseRegions= 4,
+ .regions= {
+ ERASEINFO(0x04000,1),
+ ERASEINFO(0x02000,2),
+ ERASEINFO(0x08000,1),
+ ERASEINFO(0x1,15),
+ }
+ }, {
+ .mfr_id = MANUFACTURER_FUJITSU,
.dev_id = MBM29LV650UE,
.name = "Fujitsu MBM29LV650UE",
.uaddr = {
@@ -1510,6 +1529,23 @@ static const struct amd_flash_info jedec
ERASEINFO(0x1000,256)
}
+ }, {
+ .mfr_id = MANUFACTURER_ST,
+ .dev_id = M29F800AB,
+ .name = "ST M29F800AB",
+ .uaddr = {
+ [0] = MTD_UADDR_0x0AAA_0x0555, /* x8 */
+ [1] = MTD_UADDR_0x0555_0x02AA, /* x16 */
+ },
+ .DevSize= SIZE_1MiB,
+ .CmdSet = P_ID_AMD_STD,
+ .NumEraseRegions= 4,
+ .regions= {
+ ERASEINFO(0x04000,1),
+ ERASEINFO(0x02000,2),
+ ERASEINFO(0x08000,1),
+ ERASEINFO(0x1,15),
+ }
}, {
.mfr_id = MANUFACTURER_ST, /* FIXME - CFI device?
*/
.dev_id = M29W800DT,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: retry [PATCH] partition : add support for sysv68 partitions
Hi Geert, > > What do you think of > > `default y if VME' > > or > > `default y if M68K && SYSV_FS' > > I prefer `default y if VME'. > > BTW, perhaps PPC based Motorola MVME boards use SYSV68 partition tables, > too? No, the PPC based Motorola MVME boards use the (currently not supported by linux) AIX partition tables, as do also the motorola powerstack machines. The m88k based Motorola MVME boards use the sysV68 partition tables, but m88k is not yet supported by linux. Incidentally, what is the problem you have with SYSV68_PARTITION ? On my i586 machine, code size is 434 bytes for sysv68.o + 4 bytes more in check.c Philippe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: retry [PATCH] partition : add support for sysv68 partitions
Hi Geert, On Tue, May 08, 2007 at 10:21:12PM +0200, Geert Uytterhoeven wrote: > Hi Philippe, > > On Fri, 13 Apr 2007, Philippe De Muyter wrote: > > Add support for the Motorola sysv68 disk partition table (slices in motorola > > doc). > > > > Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]> > > > > diff -r 1b54f1d81bc5 fs/partitions/Kconfig > > --- a/fs/partitions/Kconfig Thu Apr 12 15:44:52 2007 -0700 > > +++ b/fs/partitions/Kconfig Fri Apr 13 15:51:58 2007 +0200 > > @@ -236,3 +236,12 @@ config EFI_PARTITION > > help > > Say Y here if you would like to use hard disks under Linux which > > were partitioned using EFI GPT. > > + > > +config SYSV68_PARTITION > > + bool "SYSV68 partition table support" if PARTITION_ADVANCED > > + default y if M68K > ^ > > + help > > + Say Y here if you would like to be able to read the hard disk > > + partition table format used by Motorola Delta machines (using > > + sysv68). > > + Otherwise, say N. > > Bummer, I saw your patch before, but I never noticed the `default y if M68K'. > > Can you please tell me on which platforms SYSV68 partition tables are commonly > used (I guess the Motorola MVME boards?), so we can enable it by default on a The Motorola VME boards are the only ones I am aware of. I must also add that the partitions themselves are sysv partitions. > more sensible subset of M68K? Feel free to replace or suppress the `default' directive. I actually wrote that for a i586 laptop to access/reinstall disks of sysV68 machines using a USB/SCSI adapter, but I don't think `default y' is a good idea :). What do you think of `default y if VME' or `default y if M68K && SYSV_FS' Best regards Philippe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
retry [PATCH] partition : add support for sysv68 partitions
Hi all,
Add support for the Motorola sysv68 disk partition table (slices in motorola
doc).
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
diff -r 1b54f1d81bc5 fs/partitions/Kconfig
--- a/fs/partitions/Kconfig Thu Apr 12 15:44:52 2007 -0700
+++ b/fs/partitions/Kconfig Fri Apr 13 15:51:58 2007 +0200
@@ -236,3 +236,12 @@ config EFI_PARTITION
help
Say Y here if you would like to use hard disks under Linux which
were partitioned using EFI GPT.
+
+config SYSV68_PARTITION
+ bool "SYSV68 partition table support" if PARTITION_ADVANCED
+ default y if M68K
+ help
+ Say Y here if you would like to be able to read the hard disk
+ partition table format used by Motorola Delta machines (using
+ sysv68).
+ Otherwise, say N.
diff -r 1b54f1d81bc5 fs/partitions/Makefile
--- a/fs/partitions/MakefileThu Apr 12 15:44:52 2007 -0700
+++ b/fs/partitions/MakefileFri Apr 13 15:51:58 2007 +0200
@@ -17,3 +17,4 @@ obj-$(CONFIG_IBM_PARTITION) += ibm.o
obj-$(CONFIG_IBM_PARTITION) += ibm.o
obj-$(CONFIG_EFI_PARTITION) += efi.o
obj-$(CONFIG_KARMA_PARTITION) += karma.o
+obj-$(CONFIG_SYSV68_PARTITION) += sysv68.o
diff -r 1b54f1d81bc5 fs/partitions/check.c
--- a/fs/partitions/check.c Thu Apr 12 15:44:52 2007 -0700
+++ b/fs/partitions/check.c Fri Apr 13 15:51:58 2007 +0200
@@ -34,6 +34,7 @@
#include "ultrix.h"
#include "efi.h"
#include "karma.h"
+#include "sysv68.h"
#ifdef CONFIG_BLK_DEV_MD
extern void md_autodetect_dev(dev_t dev);
@@ -104,6 +105,9 @@ static int (*check_part[])(struct parsed
#endif
#ifdef CONFIG_KARMA_PARTITION
karma_partition,
+#endif
+#ifdef CONFIG_SYSV68_PARTITION
+ sysv68_partition,
#endif
NULL
};
diff -r 1b54f1d81bc5 fs/partitions/sysv68.c
--- /dev/null Thu Jan 1 00:00:00 1970 +
+++ b/fs/partitions/sysv68.cFri Apr 13 15:51:58 2007 +0200
@@ -0,0 +1,92 @@
+/*
+ * fs/partitions/sysv68.c
+ *
+ * Copyright (C) 2007 Philippe De Muyter <[EMAIL PROTECTED]>
+ */
+
+#include "check.h"
+#include "sysv68.h"
+
+/*
+ * Volume ID structure: on first 256-bytes sector of disk
+ */
+
+struct volumeid {
+ u8 vid_unused[248];
+ u8 vid_mac[8]; /* ASCII string "MOTOROLA" */
+};
+
+/*
+ * config block: second 256-bytes sector on disk
+ */
+
+struct dkconfig {
+ u8 ios_unused0[128];
+ __be32 ios_slcblk; /* Slice table block number */
+ __be16 ios_slccnt; /* Number of entries in slice table */
+ u8 ios_unused1[122];
+};
+
+/*
+ * combined volumeid and dkconfig block
+ */
+
+struct dkblk0 {
+ struct volumeid dk_vid;
+ struct dkconfig dk_ios;
+};
+
+/*
+ * Slice Table Structure
+ */
+
+struct slice {
+ __be32 nblocks;/* slice size (in blocks) */
+ __be32 blkoff; /* block offset of slice */
+};
+
+
+int sysv68_partition(struct parsed_partitions *state, struct block_device
*bdev)
+{
+ int i, slices;
+ int slot = 1;
+ Sector sect;
+ unsigned char *data;
+ struct dkblk0 *b;
+ struct slice *slice;
+
+ data = read_dev_sector(bdev, 0, §);
+ if (!data)
+ return -1;
+
+ b = (struct dkblk0 *) data;
+ if (memcmp(b->dk_vid.vid_mac, "MOTOROLA", sizeof(b->dk_vid.vid_mac))) {
+ put_dev_sector(sect);
+ return 0;
+ }
+ slices = be16_to_cpu(b->dk_ios.ios_slccnt);
+ i = be32_to_cpu(b->dk_ios.ios_slcblk);
+ put_dev_sector(sect);
+
+ data = read_dev_sector(bdev, i, §);
+ if (!data)
+ return -1;
+
+ slices -= 1; /* last slice is the whole disk */
+ printk("sysV68: %s(s%u)", state->name, slices);
+ slice = (struct slice *)data;
+ for (i = 0 ; i < slices; i++, slice++) {
+ if (slot == state->limit)
+ break;
+ if (be32_to_cpu(slice->nblocks)) {
+ put_partition(state, slot,
+ be32_to_cpu(slice->blkoff),
+ be32_to_cpu(slice->nblocks));
+ printk("(s%u)", i);
+ }
+ slot++;
+ }
+ printk("\n");
+ put_dev_sector(sect);
+ return 1;
+}
diff -r 1b54f1d81bc5 fs/partitions/sysv68.h
--- /dev/null Thu Jan 1 00:00:00 1970 +
+++ b/fs/partitions/sysv68.hFri Apr 13 15:51:58 2007 +0200
@@ -0,0 +1,1 @@
+extern int sysv68_partition(struct parsed_partitions *state, struct
block_device *bdev);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] partition : add support for sysv68 partitions
Hi all,
Add support for the Motorola sysv68 disk partition (slices in motorola doc).
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
diff -ruN fs/partitionsbk/check.c fs/partitions/check.c
--- fs/partitionsbk/check.c 2006-09-20 05:42:06.0 +0200
+++ fs/partitions/check.c 2007-04-06 10:52:21.0 +0200
@@ -34,6 +34,7 @@
#include "ultrix.h"
#include "efi.h"
#include "karma.h"
+#include "sysv68.h"
#ifdef CONFIG_BLK_DEV_MD
extern void md_autodetect_dev(dev_t dev);
@@ -105,6 +106,9 @@
#ifdef CONFIG_KARMA_PARTITION
karma_partition,
#endif
+#ifdef CONFIG_SYSV68_PARTITION
+ sysv68_partition,
+#endif
NULL
};
diff -ruN fs/partitionsbk/Kconfig fs/partitions/Kconfig
--- fs/partitionsbk/Kconfig 2006-09-20 05:42:06.0 +0200
+++ fs/partitions/Kconfig 2007-04-04 15:14:57.0 +0200
@@ -237,3 +237,12 @@
Say Y here if you would like to use hard disks under Linux which
were partitioned using EFI GPT. Presently only useful on the
IA-64 platform.
+
+config SYSV68_PARTITION
+ bool "SYSV68 partition table support" if PARTITION_ADVANCED
+ default y if M68K
+ help
+ Say Y here if you would like to be able to read the hard disk
+ partition table format used by Motorola Delta machines (using
+ sysv68).
+ Otherwise, say N.
diff -ruN fs/partitionsbk/Makefile fs/partitions/Makefile
--- fs/partitionsbk/Makefile2006-09-20 05:42:06.0 +0200
+++ fs/partitions/Makefile 2007-04-04 15:53:01.0 +0200
@@ -17,3 +17,4 @@
obj-$(CONFIG_IBM_PARTITION) += ibm.o
obj-$(CONFIG_EFI_PARTITION) += efi.o
obj-$(CONFIG_KARMA_PARTITION) += karma.o
+obj-$(CONFIG_SYSV68_PARTITION) += sysv68.o
diff -ruN fs/partitionsbk/sysv68.c fs/partitions/sysv68.c
--- fs/partitionsbk/sysv68.c1970-01-01 01:00:00.0 +0100
+++ fs/partitions/sysv68.c 2007-04-06 16:34:33.0 +0200
@@ -0,0 +1,92 @@
+/*
+ * fs/partitions/sysv68.c
+ *
+ * Copyright (C) 2007 Philippe De Muyter <[EMAIL PROTECTED]>
+ */
+
+#include "check.h"
+#include "sysv68.h"
+
+/*
+ * Volume ID structure: on first 256-bytes sector of disk
+ */
+
+struct volumeid {
+ u8 vid_unused[248];
+ u8 vid_mac[8]; /* ASCII string "MOTOROLA" */
+};
+
+/*
+ * config block: second 256-bytes sector on disk
+ */
+
+struct dkconfig {
+ u8 ios_unused0[128];
+ __be32 ios_slcblk; /* Slice table block number */
+ __be16 ios_slccnt; /* Number of entries in slice table */
+ u8 ios_unused1[122];
+};
+
+/*
+ * combined volumeid and dkconfig block
+ */
+
+struct dkblk0 {
+ struct volumeid dk_vid;
+ struct dkconfig dk_ios;
+};
+
+/*
+ * Slice Table Structure
+ */
+
+struct slice {
+ __be32 nblocks;/* slice size (in blocks) */
+ __be32 blkoff; /* block offset of slice */
+};
+
+
+int sysv68_partition(struct parsed_partitions *state, struct block_device
*bdev)
+{
+ int i, slices;
+ int slot = 1;
+ Sector sect;
+ unsigned char *data;
+ struct dkblk0 *b;
+ struct slice *slice;
+
+ data = read_dev_sector(bdev, 0, §);
+ if (!data)
+ return -1;
+
+ b = (struct dkblk0 *) data;
+ if (memcmp(b->dk_vid.vid_mac, "MOTOROLA", sizeof(b->dk_vid.vid_mac))) {
+ put_dev_sector(sect);
+ return 0;
+ }
+ slices = be16_to_cpu(b->dk_ios.ios_slccnt);
+ i = be32_to_cpu(b->dk_ios.ios_slcblk);
+ put_dev_sector(sect);
+
+ data = read_dev_sector(bdev, i, §);
+ if (!data)
+ return -1;
+
+ slices -= 1; /* last slice is the whole disk */
+ printk("sysV68: %s(s%u)", state->name, slices);
+ slice = (struct slice *)data;
+ for (i = 0 ; i < slices; i++, slice++) {
+ if (slot == state->limit)
+ break;
+ if (be32_to_cpu(slice->nblocks)) {
+ put_partition(state, slot,
+ be32_to_cpu(slice->blkoff),
+ be32_to_cpu(slice->nblocks));
+ printk("(s%u)", i);
+ }
+ slot++;
+ }
+ printk("\n");
+ put_dev_sector(sect);
+ return 1;
+}
diff -ruN fs/partitionsbk/sysv68.h fs/partitions/sysv68.h
--- fs/partitionsbk/sysv68.h1970-01-01 01:00:00.0 +0100
+++ fs/partitions/sysv68.h 2007-04-06 16:30:22.0 +0200
@@ -0,0 +1 @@
+extern int sysv68_partition(struct parsed_partitions *state, struct
block_device *bdev);
--
Philippe De Muyter phdm at macqel dot be Tel +32 27029044
Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077
-
To unsubscribe from this list
Re: [PATCH 2.6.20] isdn-capi: Use ARRAY_SIZE macro when appropriate
On Wed, Feb 07, 2007 at 09:41:00PM +0200, Ahmed S. Darwish wrote:
> On Tue, Feb 06, 2007 at 10:18:14PM +0100, Philippe De Muyter wrote:
> > On Tue, Feb 06, 2007 at 10:41:30PM +0200, Ahmed S. Darwish wrote:
> > >
> > > -for (i=nelem-1; i >= 0; i--) {
> > > +for (i = ARRAY_SIZE(procfsentries) - 1; i >= 0; i--) {
> >
> > I would write such decrementing loops as :
> >
> >for (i = ARRAY_SIZE(procfsentries); --i >= 0; ) {
> >
> > Long time ago, that produced better code. I did not check recently though.
> [...]
> > > -for (i=nelem-1; i >= 0; i--) {
> > > +for (i = ARRAY_SIZE(procfsentries) - 1; i >= 0; i--) {
> >
> > Same here
>
> Hi Philippe,
>
> Won't this hurt readability ?. I'm not a gcc guru anyway to have an
> opinion on such stuff :).
Personaly, I find it more readable, but that's a question of habit or a
matter of taste.
Philippe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fbdev driver for S3 Trio/Virge
On Mon, Feb 05, 2007 at 08:51:30PM +0100, Ondrej Zajicek wrote: > This patch adds driver for S3 Trio / S3 Virge. Driver is tested > with most versions of S3 Trio and S3 Virge, on i386. > It is tested both as compiled-in and module. It is against > linux-2.6.20 . I would like to test your patch, because I have such boards. How would you suggest to test, because of course, If I loose my screen, I won't be able to test further. Currently my X server is configured for VESA. Philippe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] isdn-capi: Use ARRAY_SIZE macro when appropriate
On Tue, Feb 06, 2007 at 10:41:30PM +0200, Ahmed S. Darwish wrote:
> On Tue, Feb 06, 2007 at 09:52:17AM -0800, Joe Perches wrote:
> > On Tue, 2007-02-06 at 18:04 +0200, Ahmed S. Darwish wrote:
> > > A patch to use ARRAY_SIZE macro already defined in kernel.h
> > > Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
> [...]
> > > -int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
> > > +int nelem = ARRAY_SIZE(procfsentries);
> > > int i;
> > >
> > > for (i=0; i < nelem; i++) {
> >
> > For these patches, perhaps you can eliminate the temporary
> > variable and change the loop to the more common form of
> >
> > for (i = 0; i < ARRAY_SIZE(array); i++) {
>
> Thanks, I think it's better too. Here's the modified patch.
>
> A patch to use ARRAY_SIZE macro when appropriate.
>
> Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/isdn/capi/capi.c b/drivers/isdn/capi/capi.c
> index d22c022..87fe89c 100644
> --- a/drivers/isdn/capi/capi.c
> +++ b/drivers/isdn/capi/capi.c
> @@ -1456,10 +1456,9 @@ static struct procfsentries {
>
> static void __init proc_init(void)
> {
> -int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
> int i;
>
> -for (i=0; i < nelem; i++) {
> +for (i = 0; i < ARRAY_SIZE(procfsentries); i++) {
> struct procfsentries *p = procfsentries + i;
> p->procent = create_proc_entry(p->name, p->mode, NULL);
> if (p->procent) p->procent->read_proc = p->read_proc;
> @@ -1468,10 +1467,9 @@ static void __init proc_init(void)
>
> static void __exit proc_exit(void)
> {
> -int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
> int i;
>
> -for (i=nelem-1; i >= 0; i--) {
> +for (i = ARRAY_SIZE(procfsentries) - 1; i >= 0; i--) {
I would write such decrementing loops as :
for (i = ARRAY_SIZE(procfsentries); --i >= 0; ) {
Long time ago, that produced better code. I did not check recently though.
> struct procfsentries *p = procfsentries + i;
> if (p->procent) {
> remove_proc_entry(p->name, NULL);
> diff --git a/drivers/isdn/capi/capidrv.c b/drivers/isdn/capi/capidrv.c
> index c4d438c..cff5d1e 100644
> --- a/drivers/isdn/capi/capidrv.c
> +++ b/drivers/isdn/capi/capidrv.c
> @@ -2218,10 +2218,9 @@ static struct procfsentries {
>
> static void __init proc_init(void)
> {
> -int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
> int i;
>
> -for (i=0; i < nelem; i++) {
> +for (i = 0; i < ARRAY_SIZE(procfsentries); i++) {
> struct procfsentries *p = procfsentries + i;
> p->procent = create_proc_entry(p->name, p->mode, NULL);
> if (p->procent) p->procent->read_proc = p->read_proc;
> @@ -2230,10 +2229,9 @@ static void __init proc_init(void)
>
> static void __exit proc_exit(void)
> {
> -int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
> int i;
>
> -for (i=nelem-1; i >= 0; i--) {
> +for (i = ARRAY_SIZE(procfsentries) - 1; i >= 0; i--) {
Same here
> struct procfsentries *p = procfsentries + i;
> if (p->procent) {
> remove_proc_entry(p->name, NULL);
>
>
Philippe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
On Sun, Jan 07, 2007 at 06:10:30PM -0800, David Brownell wrote: > > One usefull addition for my needs and with a m41t81 is the support of > > the calibration of the rtc. However this can perhaps be hidden in the > > .set_mmss function. > > Doesn't seem like an set_mmss() mechanism at all. Some drivers give > sysfs access to an oscillator "trim" mechanism. What tools do you > have which track how far off that crystal is? ntp, either from network or from a radio-clock and using set_mmss for that purpose seems not so disgusting, because : - writing to the clock (the expected work of set_mmss) must be disabled when we observe the clock drift - set_mmss is always called with a very good precision, so one could use the time given to set_mmss to compare it to the time given by the RTC over a long enough period of time (more than 11 minutes) to compute the RTC's drift and the necessary adjustment. Of course, if we want something that is not based on ntp, then we may not overload set_mmss. Philippe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
On Sun, 7 Jan 2007, Hugh Dickins wrote: > Author: Matt Mackall <[EMAIL PROTECTED]> > > [PATCH] RTC: Remove RTC UIP synchronization on x86 > > Reading the CMOS clock on x86 and some other arches currently takes up to > one > second because it synchronizes with the CMOS second tick-over. This delay > shows up at boot time as well a resume time. That is true if kernel's idea of an RTC's precision is 1 second. With better RTC's (e.g. m41t81) this delay can be reduced to 0.01 second, which is acceptable IMHO in the boot phase. That needs however changes in the kernel interface to RTC's : - read_time should take a new parameter *nsec (or struct rtc_time should contain a new nsec field, so that the RTC can report its complete time information to the kernel. - struct rtc_device (or rtc_class_ops with another name) should contain a new field giving the RTC's resolution in nsecs, if we want to avoid the loop, but do not want our 0.01 second precision be destructed by always adding 0.5 second in rtc_hctosys Philippe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
On Fri, Jan 05, 2007 at 07:49:00PM -0800, David Brownell wrote: > > Those rtc's actually have a 1/100th of second > > register. Should the generic rtc interface not support that? > > Are you implying a new userspace API, or just an in-kernel update? > > Either way, that raises the question of what other features should > be included. What sub-second precision? Multiple alarms? Ways > to manage output clocks? Sub-HZ periodic alarms? One usefull addition for my needs and with a m41t81 is the support of the calibration of the rtc. However this can perhaps be hidden in the .set_mmss function. Philippe -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
On Sat, Jan 06, 2007 at 03:52:43PM -0800, David Brownell wrote: > On Saturday 06 January 2007 3:26 pm, Philippe De Muyter wrote: > > On Fri, Jan 05, 2007 at 07:49:00PM -0800, David Brownell wrote: > > > > Those rtc's actually have a 1/100th of second > > > > register. Should the generic rtc interface not support that? > > > > > > Are you implying a new userspace API, or just an in-kernel update? > > > > My only concern at the moment is initializing linux's timeofday from the rtc > > quickly and with a good precision. > > There will necessarily be a bit of fuzz there since it can take time to > get that RTC's mutex, and the task setting that time can be preempted. > Plus, there can also be delays at the I2C or SPI transaction level. > > > > The way it is done currently > > in drivers/rtc/hctosys.c is 0.5 sec off. We could obtain a much better > > precision by looping there until the next change (next second for old > > clocks, > > next 0.01 second for m41t81, maybe even better for other ones). > > Hmm ... "looping" fights against "quickly"; as would "wait for next > update IRQ" (on RTCs that support that). But it would improve precision, > at least in the sense of having the system clock and that RTC spending > less time with the lowest "seconds" digit disagreeing. > > This is something you could write a patch for, n'est-ce pas? That would require changing the interface provided by the rtc class, but I'll look at it. > > - Dave > > -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
On Fri, Jan 05, 2007 at 07:49:00PM -0800, David Brownell wrote: > > Those rtc's actually have a 1/100th of second > > register. Should the generic rtc interface not support that? > > Are you implying a new userspace API, or just an in-kernel update? My only concern at the moment is initializing linux's timeofday from the rtc quickly and with a good precision. The way it is done currently in drivers/rtc/hctosys.c is 0.5 sec off. We could obtain a much better precision by looping there until the next change (next second for old clocks, next 0.01 second for m41t81, maybe even better for other ones). > > Either way, that raises the question of what other features should > be included. What sub-second precision? Multiple alarms? Ways > to manage output clocks? Sub-HZ periodic alarms? I cannot answer that, but others may have other needs. Philippe -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RTC subsystem and fractions of seconds
Hi all, A comment in driver/rtc/hctosys says : /* IMPORTANT: the RTC only stores whole seconds. It is arbitrary * whether it stores the most close value or the value with partial * seconds truncated. However, it is important that we use it to store * the truncated value. This is because otherwise it is necessary, * in an rtc sync function, to read both xtime.tv_sec and * xtime.tv_nsec. On some processors (i.e. ARM), an atomic read * of >32bits is not possible. So storing the most close value would * slow down the sync API. So here we have the truncated value and * the best guess is to add 0.5s. */ I work with ST m41t81 rtc's. Those rtc's actually have a 1/100th of second register. Should the generic rtc interface not support that ? Philippe -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
