> correct solution is that it does not need to be freed (explicitly) at
> all. That's the whole point of the managed allocators (i.e.,
> devm_kzalloc()). Try this patch instead. Totally untested here.
Pushed to l2-mtd.git, thanks!
--
Best Regards,
Artem Bityutskiy
_
On Mon, 2013-03-11 at 09:20 -0700, Olof Johansson wrote:
> On Mon, Mar 11, 2013 at 8:34 AM, Artem Bityutskiy wrote:
> > Hi MTD folks,
> >
> > we have huge amount of drivers, espacially mapping drives in
> > 'drivers/mtd', and for sure may of them are for an
iling list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
From: Artem Bityutskiy
This driver depends on the CONFIG_DBOX2 symbol which does not exist in
the kernel, which means the driver is dead.
Signed-off-by: Artem Bityutskiy
---
Adding the PPC list
drivers/mtd/maps/Kconfig |8 ---
drivers/mtd/maps/Makefile |1 -
drivers/mtd
From: Artem Bityutskiy
This driver depends on the CONFIG_DMV182 symbol which is not defined anywhere,
and this means that this driver is dead.
Signed-off-by: Artem Bityutskiy
---
Adding the PPC list
drivers/mtd/maps/Kconfig |9 ---
drivers/mtd/maps/Makefile |1 -
drivers/mtd/maps
From: Artem Bityutskiy
This driver depends on the CONFIG_TQM8xxL symbol, which is not defined
anywhere, which means that this driver is dead.
Signed-off-by: Artem Bityutskiy
---
Adding the PPC list
drivers/mtd/maps/Kconfig | 10 --
drivers/mtd/maps/Makefile |1 -
drivers/mtd/maps
From: Artem Bityutskiy
This driver is marked as broken for very long time. Most probably this board is
just something ancient no one cares about anyway.
Signed-off-by: Artem Bityutskiy
---
Adding the PPC list
drivers/mtd/maps/Kconfig| 16 --
drivers/mtd/maps/Makefile |1
From: Artem Bityutskiy
This driver depends on CONFIG_IXP2000 which is not defined anywhere, which means
this driver is dead.
Signed-off-by: Artem Bityutskiy
---
Adding the PPC list
drivers/mtd/maps/Kconfig |9 --
drivers/mtd/maps/Makefile |1 -
drivers/mtd/maps/ixp2000.c | 253
anks!
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tue, 2011-11-15 at 17:29 +0800, b35...@freescale.com wrote:
> From: Liu Shuo
>
> fix whitespaces,tabs coding style issue and use #include instead
> of
> in drivers/mtd/nand/fsl_elbc.c.
>
> Signed-off-by: Liu Shuo
> Signed-off-by: Li Yang
Hi, It is really matter of taste whether to use o
On Tue, 2011-11-15 at 17:29 +0800, b35...@freescale.com wrote:
> From: Liu Shuo
>
> If we use the Nand flash chip whose number of pages in a block is greater
> than 64(for large page), we must treat the low bit of FBAR as being the
> high bit of the page address due to the limitation of FCM, it s
On Tue, 2011-11-15 at 17:29 +0800, b35...@freescale.com wrote:
> + /*
> +* Freescale FCM controller has a 2K size limitation of buffer
> +* RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
> +* of chip is greater than 2048.
> +
On Fri, 2011-11-18 at 10:08 +0800, LiuShuo wrote:
> Ok and I want to add another patch before 3/3.
>
> -LiuShuo
> > On Tue, 2011-11-15 at 17:29 +0800, b35...@freescale.com wrote:
> >> From: Liu Shuo
> >>
> >> If we use the Nand flash chip whose number of pages in a block is greater
> >> than 64(fo
eater than 2048.
> +* We malloc a large enough buffer (maximum page size is 16K).
> +*/
> + elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024,
> GFP_KERNEL);
Are there NANDs with 16KiB page size?
--
Best Regards,
Artem Bityutskiy
signat
d. So I would not go for this unless this is necessary.
Did you try to look how the NAND base interface could be changed to
avoid re-allocation altogether, BTW?
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, 2011-11-24 at 18:02 +0800, LiuShuo wrote:
> 于 2011年11月24日 16:16, Artem Bityutskiy 写道:
> > On Thu, 2011-11-24 at 07:49 +, Li Yang-R58472 wrote:
> >>> Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to
> >>> support
> >>> lar
On Mon, 2011-10-31 at 17:38 +0800, b35...@freescale.com wrote:
> +/*
> + * fsl_ifc_ctrl_probe
> + *
> + * called by device layer when it finds a device matching
> + * one our driver can handled. This code allocates all of
> + * the resources needed for the controller only. The
> + * resources for
On Thu, 2011-11-24 at 08:24 -0600, Kumar Gala wrote:
> On Nov 22, 2011, at 9:41 PM, Kumar Gala wrote:
>
> >
> > On Oct 31, 2011, at 4:38 AM,
> > wrote:
> >
> >> From: Liu Shuo
> >>
> >> Integrated Flash Controller supports various flashes like NOR, NAND
> >> and other devices using NOR, NAN
#x27;d suggest to
merge it vie the same tree as the rest of the patches.
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://li
On Sun, 2011-12-04 at 12:31 +0800, shuo@freescale.com wrote:
> + /*
> + * Freescale FCM controller has a 2K size limitation of buffer
> + * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
> + * of chip is greater than 2048.
> +
On Sun, 2011-12-04 at 12:31 +0800, shuo@freescale.com wrote:
> From: Liu Shuo
>
> On both of large-page chip and small-page chip, we always should use
> 'elbc_fcm_ctrl->oob' to set the FPAR_LP_MS/FPAR_SP_MS bit of FPAR, don't
> use a overflowed 'column' to set it.
>
> Signed-off-by: Liu Shuo
On Sun, 2011-12-04 at 12:31 +0800, shuo@freescale.com wrote:
> From: Liu Shuo
>
> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
> to support the Nand flash chip whose page size is larger than 2K bytes,
> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_
On Mon, 2011-12-05 at 13:46 -0600, Scott Wood wrote:
> Because this is a controller resource, shared by multiple NAND chips
> that may be different page sizes (even if not, it's adding another point
> of synchronization required between initialization of different chips).
> I don't think it's wort
On Fri, 2011-12-09 at 17:42 +0800, shuo@freescale.com wrote:
> From: Liu Shuo
>
> If we use the Nand flash chip whose number of pages in a block is greater
> than 64(for large page), we must treat the low bit of FBAR as being the
> high bit of the page address due to the limitation of FCM, it
On Tue, 2011-12-06 at 18:09 -0600, Scott Wood wrote:
> On 12/03/2011 10:31 PM, shuo@freescale.com wrote:
> > From: Liu Shuo
> >
> > Freescale FCM controller has a 2K size limitation of buffer RAM. In order
> > to support the Nand flash chip whose page size is larger than 2K bytes,
> > we read
On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
> NAND chips come from the factory with bad blocks marked at a certain
> offset into each page. This offset is normally in the OOB area, but
> since we change the layout from "4k data, 128 byte oob" to "2k data, 64
> byte oob, 2k data, 64 byte o
On Mon, 2011-12-12 at 15:30 -0600, Scott Wood wrote:
> On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:
> > On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
> >> NAND chips come from the factory with bad blocks marked at a certain
> >> offset into each page. This of
> and not relying on the setting of bootloader.
>
> Signed-off-by: Shengzhou Liu
Pushed both to l2-mtd-2.6.git, thanks!
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing
On Wed, 2011-12-14 at 11:13 +, Li Yang-R58472 wrote:
> >-Original Message-
> >From: Artem Bityutskiy [mailto:dedeki...@gmail.com]
> >Sent: Wednesday, November 30, 2011 4:51 PM
> >To: Kumar Gala
> >Cc: Wood Scott-B07421; Li Yang-R58472; Liu Shuo-B35362; li
On Tue, 2011-12-20 at 06:40 +, Liu Shengzhou-B36685 wrote:
> > -Original Message-
> > From: Artem Bityutskiy [mailto:dedeki...@gmail.com]
> > Sent: Saturday, December 17, 2011 10:45 PM
> > To: Liu Shengzhou-B36685
> > Cc: linuxppc-dev@lists.ozlabs.
m Aggrwal
> Signed-off-by: Scott Wood
> Signed-off-by: Prabhakar Kushwaha
The driver is not in 3.3-rc1, so I skip this patch.
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-de
onfigs.
>
>
> Signed-off-by: Huang Shijie
Pushed to l2-mtd.git, thanks!
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
; - mpc5121_nfc_free(dev, mtd);
> + clk_disable(prv->clk);
> return retval;
> }
>
> @@ -857,8 +833,7 @@ static int __devexit mpc5121_nfc_remove(struct
> platform_device *op)
> struct mpc5121_nfc_prv *prv = chip->priv;
>
> nand_rel
mon as kzalloc, ioremap, etc.
It looks like Lars is going to fix this.
I am personally fine if you send patches without build-testing them.
Your patches are generally of good quality and you send many of them, so
build-testing each would be too much for you. And at least for MTD, I
can build-test
On Thu, 2012-09-13 at 07:53 -0500, Kumar Gala wrote:
> > drivers/mtd/nand/fsl_ifc_nand.c | 56
> > ++-
> > 1 file changed, 55 insertions(+), 1 deletion(-)
>
> If MTD maintainers ack, I'm happy to pull this in via PPC tree
fore issuing command.
>
> NAND_CMD_READID command implemention does not fulfill above requirement. So
> update its programming.
>
> Signed-off-by: Prabhakar Kushwaha
> Signed-off-by: Hemant Nautiyal
Pushed to l2-mtd.git, thanks!
--
Best Regards,
Artem Bityutskiy
signat
kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Branch master
Pushed to l2-mtd.git, thanks!
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Signed-off-by: Frank Svendsboe
Cc: sta...@kernel.org [3.2+]
Signed-off-by: Artem Bityutskiy
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
TD_PLATRAM) += plat-ram.o
obj-$(CONFIG_MTD_INTEL_VR_NOR) += intel_vr_nor.o
I've amended the patch and pushed to l2-mtd.git tree, thanks!
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is a digitally signed message part
Pushed to l2-mtd-2.6.git, thanks!
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
anks.
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Sat, 2010-10-16 at 19:05 -0600, Grant Likely wrote:
> On Sat, Oct 16, 2010 at 1:17 PM, Artem Bityutskiy wrote:
> > On Tue, 2010-10-12 at 18:18 +0800, Mingkai Hu wrote:
> >> Signed-off-by: Mingkai Hu
> >> Acked-by: Grant Likely
> >> ---
> >> v4
ge collector process, that looks
> for CLEANMARKER-nodes
>
> As Scott said it was broken by commit 3ab8f2a2e7011c5e83363b42950757e46ef06824
>
> Signed-off-by: Sergej Stepanov
> Cc: Rolf Riehle
> Cc: Scott Wood
> Cc: David Woodhouse
Pusehd to
91113 ("UBI: allocate write checking buffer on
> demand").
>
> I don't know how to fix this, so I have left it for today.
Hmm, strange, include should be enough to use
__vmalloc with 'PAGE_KERNEL' AFAICS, and we have this include... I'll
try to look better
On Wed, 2011-03-16 at 21:15 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2011-03-16 at 09:22 +0200, Artem Bityutskiy wrote:
> > On Wed, 2011-03-16 at 17:50 +1100, ext Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the final tre
ocate write checking buffer on
> demand").
>
> I don't know how to fix this, so I have left it for today.
Fixed, sorry for the hassle and thank you!
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, 2009-08-19 at 01:44 +0400, Anton Vorontsov wrote:
> On Mon, Aug 10, 2009 at 10:35:23AM +0300, Artem Bityutskiy wrote:
> > On Fri, 2009-07-31 at 04:39 +0400, Anton Vorontsov wrote:
> > > Andrew,
> > >
> > > This new patch set overwrites following patche
t; if NOR is accessed while a NAND operation is in progress, the NAND operation
> will fail.
>
> Signed-off-by: Scott Wood
Taken the patches to my l2-mtd-2.6 tree.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mail
ions
exists as an MTD concept? Why different regions could not be
represented as different MTD devices? The benefit is - simplicity.
Thanks.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Thu, 2009-04-16 at 14:52 +0200, Stefan Roese wrote:
> On Thursday 16 April 2009, Artem Bityutskiy wrote:
> > On Thu, 2009-04-16 at 14:05 +0200, Stefan Roese wrote:
> > > This patchset adds support to handle multiple non-identical chips in one
> > > flash device tre
ne into -next for some testing
> exposure. Unless he asks me to do otherwise, I'll leave this one to
> David to pick up.
David usually picks up stuff just before or during merge window,
so if you want linux-next exposure, you need to have some extra
care.
--
Best regards,
Artem Bityut
On Thu, 2009-04-16 at 19:38 +0100, David Woodhouse wrote:
> On Thu, 16 Apr 2009, Artem Bityutskiy wrote:
>
> > On Thu, 2009-04-16 at 07:46 -0600, Grant Likely wrote:
> >> On Thu, Apr 16, 2009 at 7:37 AM, Stefan Roese wrote:
> >>> On Thursday 16 April 2009, Grant
rs/mtd/nand/mpc5121_nfc.c | 916
> ++++++++
> 3 files changed, 924 insertions(+), 0 deletions(-)
> create mode 100644 drivers/mtd/nand/mpc5121_nfc.c
Pushed to my l2-mtd-2.6.git / dunno.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
g issues on this patch with arch-specific
> code. If the patch looks okay to you, then can I pick it up into my
> tree?
Because of the general large response time of the MTD community, I
suggest you to go put this stuff to your tree.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
ed-off-by and re-send.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
if ((rev != 2) && (rev != 3)) {
> dev_err(dev, "SoC revision %u is not supported!\n",
> rev);
> return -ENXIO;
> }
Now your patch is line-wrapped. But I fixed it and pushed to
l2-mtd-2.6.git / master.
--
Best Regards,
Artem Bit
gt; of your trees, or do you mind if the subsystem maintainers take them
> through theirs?
But unfortunately, it is very easy to break this and for sure it'll be
broken very soon.
So additionally, I'd suggest:
1. Instrument checkpatch.pl and make it err or warn on timestamps.
2
bad
things before they are merged, rather than afterwards.
But anyway, let's forget about this.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
shed to l2-mtd-2.6.git, thanks.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
err;
> +
> +#ifdef CONFIG_MTD_OF_PARTS
> + if (ret == 0) {
> + ret = of_mtd_parse_partitions(priv->dev, node, &parts);
> + if (ret < 0)
> + goto err;
> + }
> +#endif
You should invent something to make sure you d
l-lbc ffe124000.localbus: read_byte beyond end of buffer
> fsl-lbc ffe124000.localbus: read_byte beyond end of buffer
>
Thanks!
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
force scrubbing, the easies way is to just read all volumes, like
dd if=/dev/ubi0_i of=/dev/null bs=4096
for each i.
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
n 0;
> }
Do we have to assign fsl_lbc_ctrl_dev->nand to NULL in
fsl_elbc_nand_remove() then? I think that assignment can be killed then.
if (!elbc_fcm_ctrl->counter) {
fsl_lbc_ctrl_dev->nand = NULL;
kfree(elbc_fcm_ctrl);
}
--
Best Re
his patch.
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, 2011-06-29 at 11:43 -0500, Scott Wood wrote:
> On Wed, 29 Jun 2011 09:22:04 +0300
> Artem Bityutskiy wrote:
>
> > On Tue, 2011-06-28 at 09:50 +0800, b35...@freescale.com wrote:
> > > + /* Hack for supporting the flash chip whose writesize is
> &g
On Wed, 2011-06-29 at 11:45 -0500, Scott Wood wrote:
> On Wed, 29 Jun 2011 09:20:25 +0300
> Artem Bityutskiy wrote:
>
> > On Tue, 2011-06-28 at 09:50 +0800, b35...@freescale.com wrote:
> > > From: Liu Shuo
> > >
> > > The global data fsl_lb
one.
> Then you're referencing freed memory.
Oh, then this sounds like a separate bug. Removing the module should
kill everything, and re-inserging the module should have zero
dependencies on the previous states...
Anyway, if you think the original patch is OK, I can put it to my tree.
--
Best
zero.
>
> Signed-off-by: Liu Shuo
Changed the subject to something shorted and pushed to l2-mtd-2.6.git,
thanks.
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
or this read is always -1, so the read
> will never work correctly. Remove this useless (and potentially problematic)
> block of code.
Pushed to l2-mtd-2.6.git, thanks!
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@l
Hench
Pushed to l2-mtd-2.6.git, thanks.
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
}
So basically if the flash has 4KiB NAND pages, you are considering it as
a flash with 2KiB NAND pages. But surely this will work only if the
underlying flash has NOP 2 at least. Or even, if you consider that JFFS2
and YAFFS want to write to OOB, you need NOP 4 (2 ECC writes and 2
wr
On Mon, 2011-08-15 at 11:11 -0500, Scott Wood wrote:
> On 08/15/2011 10:59 AM, Artem Bityutskiy wrote:
> > On Tue, 2011-07-12 at 12:48 +0800, b35...@freescale.com wrote:
> >> + /*
> >> + * Hack for supporting the flash chip whose writesize is
>
rmsg("%s: unable to get
> NAND ecclayout", mtd_device);
> +
Hmm, shouldn't we instead make MTD_OOB_AUTO be available for userspace
via an ioctl instead and make flash_eraseall use it instead?
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ven start physically removing depricated ioctls by
first adding a printk with a warning and then removing completely. But
first mtdutils should be updated to not use them.
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ind of info to the driver code comments?
Does it also make sense to print a message if you do the emulation,
like:
pr_info("attention! emulating 2KiB NAND pages!");
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
> > How the bad block marker are handled with this remapping ?
>
> It has to be migrated prior to first use (this needs to be documented,
> and ideally a U-Boot command provided do do this), or else special
> handling would be needed when b
On Mon, 2011-08-22 at 10:58 -0500, Scott Wood wrote:
> On 08/22/2011 05:58 AM, Artem Bityutskiy wrote:
> > On Fri, 2011-08-19 at 13:10 -0500, Scott Wood wrote:
> >> On 08/19/2011 03:57 AM, Matthieu CASTET wrote:
> >>> How the bad block marker are handled with this r
dev
nand_flash_ids' ?
4. Can we add a NOP field to 'struct nand_flash_dev nand_flash_ids'
array?
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
;21cn...@gmail.com>
> Signed-off-by: Anton Vorontsov
> ---
Pushed both patches to my l2-mtd-2.6.git / dunno, added Mike's ack.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ke it
> in via mine if the netdev and MTD people are fine with that. Otherwise,
> my ack is below.
>
> Acked-by: Josh Boyer
You know how slow MTD people may be sometimes, so I'd suggest you to
merge this via whatever tree. David is in CC, he'll com
On Mon, 2010-08-09 at 15:33 +0800, Zang Roy-R61911 wrote:
> Any comment about this serial patches?
> If none, I'd ask Andrew to merge to his mm tree.
Could you please separate out MTD stuff, to the extent it is possible to
do?
--
Best Regards,
Artem Bityutskiy (Бит
dge which
type is better in this case. I am talking in general. :-)
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Mon, 2010-09-13 at 09:35 -0500, Timur Tabi wrote:
> On Mon, Sep 13, 2010 at 9:27 AM, Artem Bityutskiy wrote:
>
> > Yes, sizeof(int) == 4 assumption is not good.
> >
> > But sizeof(int) >= 4 is perfectly fine.
>
> I have to disagree. I don't see how
On Mon, 2010-09-13 at 13:36 -0500, Timur Tabi wrote:
> On Mon, Sep 13, 2010 at 11:45 AM, Artem Bityutskiy
> wrote:
> > Unsigned int is reliably >= 4 in Linux.
>
> Not exactly. sizeof(unsigned int) is effectively never greater than 4
> in Linux
I know and said the sam
t.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Subrata Modak wrote:
On Fri, 2009-07-10 at 08:59 +0300, Artem Bityutskiy wrote:
On Mon, 2009-07-06 at 07:47 +0530, Subrata Modak wrote:
Hi,
Is there somebody else whom i should also address to get an attention
for this patch ? I apolozise if i have not included someone. Kindly
connect to the
On Fri, 2009-07-10 at 12:42 +0530, Subrata Modak wrote:
> On Fri, 2009-07-10 at 09:18 +0300, Artem Bityutskiy wrote:
> > Subrata Modak wrote:
> > > On Fri, 2009-07-10 at 08:59 +0300, Artem Bityutskiy wrote:
> > >> On Mon, 2009-07-06 at 07:47 +0530, S
to me.
>
> Acked-by: Grant Likely
This patch is sitting in my l2-mtd-2.6.git tree.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ia the MTD tree or
they better go as a series via some other tree?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Mon, 2009-08-10 at 18:19 +0200, Wolfram Sang wrote:
> On Sun, Aug 09, 2009 at 08:17:23AM +0300, Artem Bityutskiy wrote:
> > On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote:
> > > On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sang
> > > wrote:
> > > > U
On 08/10/2009 07:19 PM, Wolfram Sang wrote:
On Sun, Aug 09, 2009 at 08:17:23AM +0300, Artem Bityutskiy wrote:
On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote:
On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sang wrote:
Use physmap_of to access RAMs as mtd and add documenation for it. This
91 matches
Mail list logo
