On Wed, 29 Apr 2020 22:33:37 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> Hi Boris,
>
> On 29/4/2020 10:22 pm, Boris Brezillon wrote:
> > On Wed, 29 Apr 2020 18:42:05 +0800
> > "Ramuthevar, Vadivel MuruganX"
> > wrote:
> >
> >
On Wed, 29 Apr 2020 18:42:05 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> +
> +#define EBU_ADDR_SEL(n) (0x20 + (n) * 4)
> +#define EBU_ADDR_MASK(5 << 4)
It's still unclear what ADDR_MASK is for. Can you add a comment
explaining what it does?
> +#define
On Wed, 29 Apr 2020 21:29:40 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> Hi Boris,
>
> Thank you very much for the review comments and your time..
>
> On 29/4/2020 7:33 pm, Boris Brezillon wrote:
> > On Wed, 29 Apr 2020 18:42:05 +0800
> > &qu
On Wed, 29 Apr 2020 18:42:05 +0800
"Ramuthevar,Vadivel MuruganX"
wrote:
> +#define NAND_WRITE_CMD (EBU_CON_CS_P_LOW | HSNAND_CLE_OFFS)
> +#define NAND_WRITE_ADDR (EBU_CON_CS_P_LOW | HSNAND_ALE_OFFS)
> +
I thought we agreed on dropping those definitions.
On Wed, 29 Apr 2020 15:31:35 +0800
masonccy...@mxic.com.tw wrote:
> Hi Pratyush,
>
>
> > > > > On Tue, 21 Apr 2020 14:39:42 +0800
> > > > > Mason Yang wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > This is repost of patchset from Boris Brezillon's
> > > > > > [RFC,00/18] mtd:
On Mon, 21 Oct 2019 16:40:57 +0800
masonccy...@mxic.com.tw wrote:
> Hi Boris,
>
>
> > > > > > > Then fill-in these two hooks from the manufacturer code,
> without
> > > the
> > > > > > > postponed init.
> > > > > > >
> > > > > >
> > > > > > But in the final of nand_scan_tail(),
On Mon, 21 Oct 2019 15:23:57 +0800
masonccy...@mxic.com.tw wrote:
> Hi Miquel,
>
>
> > > > > Then fill-in these two hooks from the manufacturer code, without
> the
> > > > > postponed init.
> > > > >
> > > >
> > > > But in the final of nand_scan_tail(), mtd->_lock/_unlock will be
> > > >
On Thu, 10 Oct 2019 16:40:19 +0800
Fuqian Huang wrote:
> Avoid printing the address of l440gx_map.virt every time l440gx init.
>
> Signed-off-by: Fuqian Huang
> ---
> drivers/mtd/maps/l440gx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/maps/l440gx.c
On Tue, 24 Sep 2019 07:46:21 +
wrote:
> From: Tudor Ambarus
>
> In case the write of the first byte failed, retlen was incorrectly
> incremented to *retlen += actual; on the exit path. retlen should be
> incremented when actual data was written to the flash.
>
> Rename 'sst_write_err'
On Tue, 24 Sep 2019 07:46:15 +
wrote:
> From: Tudor Ambarus
>
> static int read_cr(struct spi_nor *nor)
> becomes
> static int spi_nor_read_cr(struct spi_nor *nor, u8 *cr)
>
> The new function returns 0 on success and -errno otherwise.
> We let the callers pass the pointer to the buffer
On Tue, 24 Sep 2019 07:46:18 +
wrote:
> From: Tudor Ambarus
>
> static int write_enable(struct spi_nor *nor)
> static int write_disable(struct spi_nor *nor)
> become
> static int spi_nor_write_enable(struct spi_nor *nor)
> static int spi_nor_write_disable(struct spi_nor *nor)
>
> Check
On Tue, 24 Sep 2019 07:46:12 +
wrote:
> From: Tudor Ambarus
>
> static int read_fsr(struct spi_nor *nor)
> becomes
> static int spi_nor_read_fsr(struct spi_nor *nor, u8 *fsr)
>
> The new function returns 0 on success and -errno otherwise.
> We let the callers pass the pointer to the
On Tue, 24 Sep 2019 07:46:08 +
wrote:
> From: Tudor Ambarus
>
> static int read_sr(struct spi_nor *nor)
> becomes
> static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
>
> The new function returns 0 on success and -errno otherwise.
> We let the callers pass the pointer to the buffer
On Tue, 24 Sep 2019 07:46:03 +
wrote:
> From: Tudor Ambarus
>
> Rename nor->params to nor->flash for a clearer separation
> between the controller and flash operations.
Hm, I'm not sure 'flash' is clearer than 'params', and the spi_nor
object is supposed to represent the NOR chip anyway,
> Going furher, the opcode was passed to cqspi_calc_rdreg() and never used,
> drop it.
>
> Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
> ---
> drivers/mtd/spi-nor/cadence-quadspi.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
&
_buf to buf, the name of the functions are
> suggestive enough. Constify buf in int (*write_reg). Comply with these
> changes in the SPI NOR controller drivers.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
> ---
>
On Tue, 24 Sep 2019 07:45:50 +
wrote:
> From: Tudor Ambarus
>
> The pointer to 'struct spi_nor' is kzalloc'ed above in the code.
>
> Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
> ---
> drivers/mtd/spi-nor/hisi-sfc.c | 1 -
> 1 file changed, 1 del
On Tue, 8 Oct 2019 10:06:50 +0800
masonccy...@mxic.com.tw wrote:
> > > + nand_select_target(chip, 0);
> >
> > On several NAND controllers there is no way to act on the CS line
> > without actually writing bytes to the NAND chip. So basically this
> > is very likely to not work.
>
> any
On Mon, 19 Aug 2019 09:03:38 +
"Shivamurthy Shastri (sshivamurthy)" wrote:
> >
> > > static int micron_spinand_detect(struct spinand_device *spinand)
> > > {
> > > + const struct spi_mem_op *op;
> > > u8 *id = spinand->id.data;
> > > - int ret;
> > >
> > > /*
> > >* Micron SPI
On Mon, 19 Aug 2019 11:21:18 +0200
Miquel Raynal wrote:
> Hi Boris,
>
> Another question for you :)
>
> "Shivamurthy Shastri (sshivamurthy)" wrote on
> Mon, 19 Aug 2019 08:51:52 +:
>
> > Hi Miquel,
> >
> > >
> > > Hi Shiva,
> > >
> > > shiva.linuxwo...@gmail.com wrote on Mon, 22 Jul
quot;).
>
> Note that this shouldn't have caused any functional issues at runtime,
> since the offset of the struct mtd_info within struct nand_chip is 0
> making mtd_to_nand() effectively a type-cast.
>
> Signed-off-by: Paul Burton
> Fixes: 7e534323c416 ("mtd: rawnand:
On Thu, 3 Oct 2019 17:37:40 +
Vitor Soares wrote:
> Hi Boris,
>
> From: Boris Brezillon
> Date: Thu, Oct 03, 2019 at 15:29:43
>
> > On Thu, 5 Sep 2019 12:00:35 +0200
> > Vitor Soares wrote:
> >
> > > The newdev->boardinfo assignment was m
On Thu, 5 Sep 2019 12:00:35 +0200
Vitor Soares wrote:
> The newdev->boardinfo assignment was missing in
> i3c_master_add_i3c_dev_locked() and hence the ->of_node info isn't
> propagated to i3c_dev_desc.
>
> Fix this by trying to initialize device i3c_dev_boardinfo if available.
>
> Cc:
>
On Mon, 30 Sep 2019 12:01:28 -0400
Kamal Dasu wrote:
> Does anyone have any comments on this patch ?.
>
> Kamal
>
> On Fri, Sep 6, 2019 at 3:49 PM Kamal Dasu wrote:
> >
> > For controller drivers that use DMA and set NAND_USE_BOUNCE_BUFFER
> > option use data buffers that are not vmalloced,
Hello Linus,
Here is the I3C PR for 5.4.
Regards,
Boris
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git
Hi Geert,
On Tue, 3 Sep 2019 17:06:52 +0200
Geert Uytterhoeven wrote:
> On Thu, Apr 25, 2019 at 9:44 PM Greg Kroah-Hartman
> wrote:
> > On Sat, Mar 30, 2019 at 03:16:37PM +0100, Boris Brezillon wrote:
> > > The AT25 protocol fits pretty well in the spi-mem model. Conve
On Tue, 3 Sep 2019 12:35:50 +0200
Vitor Soares wrote:
> On pre_assing_dyn_addr() the devices that fail:
> i3c_master_setdasa_locked()
> i3c_master_reattach_i3c_dev()
> i3c_master_retrieve_dev_info()
>
> are kept in memory and master->bus.devs list. This makes the i3c devices
> without a
On Thu, 29 Aug 2019 21:04:28 +0200
Jernej Škrabec wrote:
> Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon
> napisal(a):
> > Hi Jernej,
> >
> > On Thu, 22 Aug 2019 21:44:57 +0200
> >
> > Jernej Skrabec wrote:
> > > When cod
On Thu, 29 Aug 2019 16:33:43 +
Vitor Soares wrote:
> From: Boris Brezillon
> Date: Thu, Aug 29, 2019 at 17:15:20
>
> > On Thu, 29 Aug 2019 15:57:32 +
> > Vitor Soares wrote:
> >
> > > -----Original Message-
> > > From: Boris Brezi
On Thu, 29 Aug 2019 12:19:33 +0200
Vitor Soares wrote:
> The I3C devices described in DT might not be attached to the master which
> doesn't allow to assign a specific dynamic address.
Dynamic address assignment is not the only problem here (see my
comment about missing ->of_node info). I would
On Thu, 29 Aug 2019 15:57:32 +
Vitor Soares wrote:
> -Original Message-
> From: Boris Brezillon
>
> Sent: Thursday, August 29, 2019 4:25
> PM
> To: Vitor Soares
> Cc:
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org;
> linux-...@l
On Thu, 29 Aug 2019 15:23:30 +
Vitor Soares wrote:
> From: Boris Brezillon
> Date: Thu, Aug 29, 2019 at 15:35:20
>
> > On Thu, 29 Aug 2019 13:53:24 +
> > Vitor Soares wrote:
> >
> > > Hi Boris,
> > >
> > > From: Bori
On Thu, 29 Aug 2019 15:07:08 +
Vitor Soares wrote:
> From: Boris Brezillon
> Date: Thu, Aug 29, 2019 at 15:39:41
>
> > On Thu, 29 Aug 2019 16:39:18 +0200
> > Boris Brezillon wrote:
> >
> > > On Thu, 29 Aug 2019 14:00:44 +
> > > V
On Thu, 29 Aug 2019 16:39:18 +0200
Boris Brezillon wrote:
> On Thu, 29 Aug 2019 14:00:44 +
> Vitor Soares wrote:
>
> > Hi Boris,
> >
> > From: Boris Brezillon
> > Date: Thu, Aug 29, 2019 at 11:44:57
> >
> > > On Thu, 29 A
On Thu, 29 Aug 2019 14:00:44 +
Vitor Soares wrote:
> Hi Boris,
>
> From: Boris Brezillon
> Date: Thu, Aug 29, 2019 at 11:44:57
>
> > On Thu, 29 Aug 2019 12:19:33 +0200
> > Vitor Soares wrote:
> >
> > > The I3C devices described in DT
On Thu, 29 Aug 2019 13:53:24 +
Vitor Soares wrote:
> Hi Boris,
>
> From: Boris Brezillon
> Date: Thu, Aug 29, 2019 at 11:41:15
>
> > +Przemek
> >
> > Please try to Cc active I3C contributors so they get a chance to
> > comment on your
ble
> positions on address table consecutive.
Given the number of available slots I honestly don't think it makes a
difference, but I also don't mind this change, so
Reviewed-by: Boris Brezillon
>
> Signed-off-by: Vitor Soares
> ---
> drivers/i3c/master/dw-i3c-master.c | 16
On Thu, 29 Aug 2019 12:19:34 +0200
Vitor Soares wrote:
> The I3C devices without a static address can require a specific dynamic
> address for priority reasons.
>
> Let's update the binding document to make the 'assigned-address' property
> valid if static address != 0 and add an example with
On Thu, 29 Aug 2019 12:19:33 +0200
Vitor Soares wrote:
> The I3C devices described in DT might not be attached to the master which
> doesn't allow to assign a specific dynamic address.
I remember testing this when developing the framework, so, unless
another patch regressed it, it should
+Przemek
Please try to Cc active I3C contributors so they get a chance to
comment on your patches.
On Thu, 29 Aug 2019 12:19:32 +0200
Vitor Soares wrote:
> On pre_assing_dyn_addr() the devices that fail:
> i3c_master_setdasa_locked()
> i3c_master_reattach_i3c_dev()
>
On Tue, 27 Aug 2019 10:14:21 +0200
Neil Armstrong wrote:
> To allow using formats from negociation, stop enforcing input_bus_format
^ negotiation
> in the private dw-plat-data struct.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Bor
On Thu, 22 Aug 2019 21:45:00 +0200
Jernej Skrabec wrote:
> This command is useful for explicitly flushing last decoded frame.
>
> Signed-off-by: Jernej Skrabec
Reviewed-by: Boris Brezillon
> ---
> .../staging/media/sunxi/cedrus/cedrus_video.c | 34 +++
>
ver by exposing and implementing
> V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability.
>
> Signed-off-by: Jernej Skrabec
Reviewed-by: Boris Brezillon
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 9 +
> drivers/staging/media/sunxi/cedrus/cedrus_hw.c| 8 +-
On Thu, 22 Aug 2019 21:44:54 +0200
Jernej Skrabec wrote:
> From: Hans Verkuil
>
> Add this new V4L2_DEC_CMD_FLUSH decoder command and document it.
>
> Signed-off-by: Hans Verkuil
> Signed-off-by: Jernej Skrabec
Reviewed-by: Boris Brezillon
> ---
> Documentati
Hi Jernej,
On Thu, 22 Aug 2019 21:44:57 +0200
Jernej Skrabec wrote:
> When codec supports multiple slices in one frame, VPU has to know when
> first slice of each frame is being processed, presumably to correctly
> clear/set data in auxiliary buffers.
>
> Add first_slice field to cedrus_run
On Mon, 26 Aug 2019 13:38:48 +
Schrempf Frieder wrote:
> On 26.08.19 14:40, Boris Brezillon wrote:
> > On Mon, 26 Aug 2019 12:08:58 +
> > wrote:
> >
> >> From: Tudor Ambarus
> >>
> >> nor->params.setup() configures the SPI NO
On Sun, 18 Aug 2019 21:46:04 -0500
Wenwen Wang wrote:
> In nand_scan_bbt(), a temporary buffer 'buf' is allocated through
> vmalloc(). However, if check_create() fails, 'buf' is not deallocated,
> leading to a memory leak bug. To fix this issue, free 'buf' before
> returning the error.
>
>
ad_sr
> nor->params.ops->write_sr
> nor->params.ops->read_cr
> nor->params.ops->write_sr
> We can retrieve this info starting with JESD216 revB, by checking the
> 15th DWORD of Basic Flash Parameter Table, or with later revisions of
> the standard, by
ght now the only user will be the S3AN chips, but other
> manufacturers can implement it if needed.
>
> Move spi_nor_setup() related code in order to avoid a forward
> declaration to spi_nor_default_setup().
>
> Reviewed-by: Boris Brezillon
Nitpick: R-bs should normally
On Mon, 26 Aug 2019 12:08:38 +
wrote:
> From: Tudor Ambarus
>
> All flash parameters and settings should reside inside
> 'struct spi_nor_flash_parameter'. Move the SMPT parsed erase map
> from 'struct spi_nor' to 'struct spi_nor_flash_parameter'.
>
> Please note that there is a roll-back
On Sun, 25 Aug 2019 13:19:57 +
wrote:
> On 08/25/2019 04:09 PM, Boris Brezillon wrote:
> > On Fri, 23 Aug 2019 15:53:41 +
> > wrote:
> >
> >> From: Tudor Ambarus
> >>
> >> All flash parameters and settings should reside inside
> &g
On Sun, 25 Aug 2019 12:57:35 +
wrote:
> On 08/25/2019 03:24 PM, Boris Brezillon wrote:
> > On Sat, 24 Aug 2019 12:00:48 +
> > wrote:
> >
> >> From: Tudor Ambarus
> >>
> >> Get rid of MFR handling and implement specific manufacturer
&
On Fri, 23 Aug 2019 15:53:41 +
wrote:
> From: Tudor Ambarus
>
> All flash parameters and settings should reside inside
> 'struct spi_nor_flash_parameter'. Move clear_sr_bp() from
> 'struct spi_nor' to 'struct spi_nor_flash_parameter'.
>
> Rename clear_sr_bp()/disable_block_protection() to
On Sun, 25 Aug 2019 12:23:45 +
wrote:
> On 08/25/2019 03:03 PM, Boris Brezillon wrote:
> > External E-Mail
> >
> >
> > On Sat, 24 Aug 2019 12:00:43 +
> > wrote:
> >
> >> From: Tudor Ambarus
> >>
> >> Add func
On Sat, 24 Aug 2019 12:27:12 +
wrote:
> From: Tudor Ambarus
>
> To avoid inadvertent writes during power-up, some flashes are
> write-protected by default after a power-on reset cycle.
> A Global Block-Protection Unlock command offers a single
> command cycle that unlocks the entire memory
On Sat, 24 Aug 2019 12:19:20 +
wrote:
> From: Tudor Ambarus
>
> Bring all flash parameters default initialization in
> spi_nor_legacy_params_init().
>
> Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
> ---
> drivers/mt
Tudor Ambarus
I guess you checked that nothing in the S3AN init was relying on things
done in the default_setup() implementation.
Reviewed-by: Boris Brezillon
> ---
> drivers/mtd/spi-nor/spi-nor.c | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> dif
ght now the only user will be the S3AN chips, but other
> manufacturers can implement it if needed.
>
> Move spi_nor_setup() related code in order to avoid a forward
> declaration to spi_nor_default_setup().
>
> Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
>
On Sat, 24 Aug 2019 12:00:47 +
wrote:
> From: Boris Brezillon
>
> Add the SNOR_F_HAS_LOCK flag and set it when SPI_NOR_HAS_LOCK is set
> in the flash_info entry or when it's a Micron or ST flash.
>
> Move the locking hooks in a separate struct so that we have just
>
On Sat, 24 Aug 2019 12:00:48 +
wrote:
> From: Tudor Ambarus
>
> Get rid of MFR handling and implement specific manufacturer
> default_init() fixup hooks.
>
> Signed-off-by: Tudor Ambarus
> ---
> drivers/mtd/spi-nor/spi-nor.c | 30 --
> 1 file changed, 20
pointer to a 'struct spi-nor'.
> + */
> +static void spi_nor_legacy_init_params(struct spi_nor *nor)
Nitpick: hm, I'm not a big fan of the 'legacy' term here as I'm not sure
it reflects the reality. I guess this function will stay around, and
even new NORs are not guaranteed t
'd
recommend renaming the function into default_quad_enable() (this can be
done in a separate patch).
Reviewed-by: Boris Brezillon
> +}
> +
> +static void st_micron_set_default_init(struct spi_nor *nor)
> +{
> + nor->params.quad_enable = NULL;
> +}
> +
> /**
> * spi_nor
On Fri, 23 Aug 2019 15:53:33 +
wrote:
> From: Tudor Ambarus
>
> This series is a prerequisite for the effort of moving the
> manufacturer specific code out of the SPI NOR core.
>
> The scope is to move all [FLASH-SPECIFIC] parameters and settings
> from 'struct spi_nor' to 'struct
rams.erase_map is no longer needed,
> since the SFDP code does not touch it.
>
> Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
> ---
> drivers/mtd/spi-nor/spi-nor.c | 40 +---
> include/linux/mtd/spi-nor.h | 8 +---
>
able_block_protection() to better indicate
> what the function does.
>
> Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
> ---
> drivers/mtd/spi-nor/spi-nor.c | 47
> +--
> include/linux/mtd/spi-nor.h | 5 ++---
> 2
off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
> ---
> drivers/mtd/spi-nor/spi-nor.c | 38 ++
> include/linux/mtd/spi-nor.h | 2 --
> 2 files changed, 22 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c
settings will fit inside 'struct spi_nor_flash_parameter'.
>
> Move spi_nor_hwcaps related code to avoid forward declarations.
> Add a forward declaration that we can't avoid: 'struct spi_nor' will
> be used in 'struct spi_nor_flash_parameter'.
>
> Signed-off-by: Tudor Ambarus
Reviewed-by:
zalloc
^ Zeroing
With this fixed, you can add
Reviewed-by: Boris Brezillon
> 'struct spi_nor'.
>
> Signed-off-by: Tudor Ambarus
> ---
On Fri, 9 Aug 2019 22:27:40 +0200
Arnd Bergmann wrote:
> The ARM w90x900 platform is getting removed, so this driver is obsolete.
>
> Signed-off-by: Arnd Bergmann
One less driver to convert to ->exec_op(), Yay!
Reviewed-by: Boris Brezillon
> ---
> drivers/mt
On Fri, 9 Aug 2019 18:47:08 +0300
Tomer Maimon wrote:
> On Fri, 9 Aug 2019 at 18:26, Boris Brezillon
> wrote:
>
> > On Fri, 9 Aug 2019 18:26:23 +0300
> > Tomer Maimon wrote:
> >
> > > Hi Boris,
> > >
> > > Thanks a lot for your c
On Fri, 9 Aug 2019 18:26:23 +0300
Tomer Maimon wrote:
> Hi Boris,
>
> Thanks a lot for your comment.
>
> On Thu, 8 Aug 2019 at 18:32, Boris Brezillon
> wrote:
>
> > On Thu, 8 Aug 2019 16:14:48 +0300
> > Tomer Maimon wrote:
> >
> >
> > &g
On Thu, 8 Aug 2019 16:14:48 +0300
Tomer Maimon wrote:
> +
> +static const struct spi_controller_mem_ops npcm_fiu_mem_ops = {
> + .exec_op = npcm_fiu_exec_op,
No npcm_supports_op()? That's suspicious, especially after looking at
the npcm_fiu_exec_op() (and the functions called from there)
On Thu, 8 Aug 2019 17:44:35 +0300
Tomer Maimon wrote:
> Hi Boris,
>
> On Thu, 8 Aug 2019 at 17:04, Boris Brezillon
> wrote:
>
> > Hi Tomer,
> >
> > On Thu, 8 Aug 2019 13:05:14 +0300
> > Tomer Maimon wrote:
> >
> > > @@ -688,6 +100
Hi Tomer,
On Thu, 8 Aug 2019 13:05:14 +0300
Tomer Maimon wrote:
> @@ -688,6 +1003,16 @@ static int spi_nor_erase_sector(struct spi_nor *nor,
> > u32 addr)
> > if (nor->erase)
> > return nor->erase(nor, addr);
> >
> > + if (nor->spimem) {
> > + struct
On Thu, 1 Aug 2019 17:17:29 +0800
masonccy...@mxic.com.tw wrote:
> Hi Boris,
>
> > On Thu, 1 Aug 2019 11:55:10 +0800
> > Mason Yang wrote:
> >
> > > Document the bindings used by the Macronix raw NAND controller.
> > >
> > > Signed-off-by: Mason Yang
> > > ---
> > >
On Wed, 31 Jul 2019 09:18:49 +
wrote:
> From: Tudor Ambarus
>
> Dedicate a function for getting the pointer to the flash_info
> const struct. Trim a bit the spi_nor_scan() huge function.
>
> Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
> ---
>
On Wed, 31 Jul 2019 09:18:47 +
wrote:
> From: Tudor Ambarus
>
> Parsing of flash parameters were interleaved with setting of the
> nor addr width. Dedicate a function for setting nor addr width.
>
> Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
> ---
&
On Wed, 31 Jul 2019 09:18:45 +
wrote:
> From: Tudor Ambarus
>
> Bring all flash parameters default initialization in
> spi_nor_default_params_init().
>
> Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
> ---
> drivers/mt
On Wed, 31 Jul 2019 09:12:16 +
wrote:
> From: Tudor Ambarus
>
> s3an_nor_scan() was overriding the opcode selection done in
> spi_nor_default_setup(). Set nor->setup() method in order to
> avoid unnecessary call to spi_nor_default_setup().
>
> Signed-off-by: Tudor Ambarus
> ---
>
The patch looks good otherwise.
Reviewed-by: Boris Brezillon
> * completely locked
Looks like this 'completely locked' is a leftover from a previous move
(lock functions were move to a separate _ops struct IIRC). Can you fix
that?
> * @priv:the private dat
spi_nor_sfdp_init_params()
> }
>
> spi_nor_init_params() becomes of type void, as all its children
> return void.
>
> Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
> ---
> drivers/mtd/spi-nor/spi-nor.c | 58
> ---
> 1 file c
struct spi_nor_flash_parameter *params)
So now we have spi_nor_mfr_init_params() and
spi_nor_manufacturer_init_params(), that's a bit confusing. Can't we
just inline the below code in the spi_nor_manufacturer_init_params()
func? I guess this func will be removed anyway, so maybe it's not
nufacturers get
>the serial flash tables wrong or incomplete.
> nor->info->fixups->post_sfdp()
>The later can be extended to nor->manufacturer->fixups->post_sfdp() if
>needed.
>
> This patch opens doors for steps 2/ and 3/.
>
> Signed-off
On Thu, 1 Aug 2019 11:55:09 +0800
Mason Yang wrote:
> Add a driver for Macronix raw NAND controller.
>
> Signed-off-by: Mason Yang
> ---
> drivers/mtd/nand/raw/Kconfig | 6 +
> drivers/mtd/nand/raw/Makefile| 1 +
> drivers/mtd/nand/raw/mxic_nand.c | 554
>
On Thu, 1 Aug 2019 11:55:10 +0800
Mason Yang wrote:
> Document the bindings used by the Macronix raw NAND controller.
>
> Signed-off-by: Mason Yang
> ---
> Documentation/devicetree/bindings/mtd/mxic-nand.txt | 19 +++
> 1 file changed, 19 insertions(+)
> create mode 100644
On Thu, 1 Aug 2019 10:00:51 +0530
Vignesh Raghavendra wrote:
> From: Boris Brezillon
>
> The m25p80 driver is actually a generic wrapper around the spi-mem
> layer. Not only the driver name is misleading, but we'd expect such a
> common logic to be directly available in th
id[SPI_NOR_MAX_ID_LEN];
> const struct flash_info *info;
>
> - tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
> + tmp = nor->read_reg(nor, SPINOR_OP_RDID, nor->bouncebuf,
> + SPI_NOR_MAX
On Thu, 1 Aug 2019 13:06:10 +0900
Tomasz Figa wrote:
> Hi Boris,
>
> On Wed, Jun 19, 2019 at 9:15 PM Boris Brezillon
> wrote:
> [snip]
> > @@ -533,10 +535,21 @@ hantro_queue_setup(struct vb2_queue *vq, unsigned int
> > *num_buffers,
> &g
On Wed, 31 Jul 2019 12:31:19 +
Naga Sureshkumar Relli wrote:
> Hi Tudor,
>
> Thanks for the updates. With these kind of updates, we can add Vendor specific
> Code easily, like Xilinx Dual parallel and stacked modes.
> In these configurations we need to tweak the nor parameters like
Hi Tomer,
On Mon, 29 Jul 2019 17:25:01 +0300
Tomer Maimon wrote:
> Lately we have working on Flash interface unit (FIU) SPI driver that
> using spi-mem interface, Our FIU HW module support direct Flash Rd//Wr.
>
> In our SOC (32 bit dual core ARM) we have 3 FIU's that using memory mapping
>
lso i3c capable so let's give i3c support to
> > them.
> >
> > Signed-off-by: Vitor Soares
> > Acked-by: Lorenzo Bianconi
> > Reviewed-by: Boris Brezillon
> Great. I'll pick this up once Boris has that immutable branch
> available. Give me a poke if I s
On Sat, 27 Jul 2019 09:23:33 +0800
Qii Wang wrote:
> On Wed, 2019-07-24 at 14:21 -0600, Rob Herring wrote:
> > On Tue, Jul 09, 2019 at 09:09:21PM +0800, Qii Wang wrote:
> > > Document MediaTek I3C master DT bindings.
> > >
> > > Signed-off-by: Qii Wang
> > > ---
> > >
On Thu, 25 Jul 2019 15:31:41 +0200
Rasmus Villemoes wrote:
> On 19/06/2019 14.15, Boris Brezillon wrote:
> > From: Hertz Wong
> >
> > Add helpers and patch hantro_{drv,v4l2}.c to prepare addition of H264
> > decoding support.
> >
> > Signed-off-b
On Thu, 25 Jul 2019 13:17:07 +
wrote:
> Hi, Boris,
>
> On 07/25/2019 03:37 PM, Boris Brezillon wrote:
> > External E-Mail
> >
> >
> > On Thu, 25 Jul 2019 11:19:06 +
> > wrote:
> >
> >>> + */
> >>> +
Hi Andrew,
On Wed, 19 Jun 2019 14:15:32 +0200
Boris Brezillon wrote:
> From: Rasmus Villemoes
>
> Our list_sort() utility has always supported a context argument that
> is passed through to the comparison routine. Now there's a use case
> for the similar thing for sort().
>
On Thu, 25 Jul 2019 11:19:06 +
wrote:
> > + */
> > +static int spi_nor_exec_op(struct spi_nor *nor, struct spi_mem_op *op,
> > + u64 *addr, void *buf, size_t len)
> > +{
> > + int ret;
> > + bool usebouncebuf = false;
>
> I don't think we need a bounce buffer for
ed-off-by: Hariprasad Kelam
Reviewed-by: Boris Brezillon
> ---
> drivers/staging/media/hantro/hantro_vp8.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/hantro_vp8.c
> b/drivers/staging/media/hantro/hantro_vp8.c
> index 66c4533..36
On Fri, 19 Jul 2019 15:30:54 +0200
Vitor Soares wrote:
> Some I3C device drivers need to know which entry matches the
> i3c_device object passed to the probe function
>
> Let's move i3c_device_match_id() to device.c and export it so it can be
> used by drivers.
>
> Signed-off-by: Vitor Soares
> Acked-by: Lorenzo Bianconi
Reviewed-by: Boris Brezillon
> ---
> Changes in v5:
> Move regmap_config declaration inside st_lsm6dsx_i3c_probe()
> Fix warning [-Wint-to-void-pointer-cast] when compiling in 64-bit arch
>
> Changes in v4:
> Remove hw_id variab
On Fri, 19 Jul 2019 13:19:04 +0200
Vitor Soares wrote:
> Some I3C device drivers need to know which entry matches the
> i3c_device object passed to the probe function
>
> Let's move i3c_device_match_id() to device.c and export it so it can be
> used by drivers.
>
> Signed-off-by: Vitor Soares
101 - 200 of 10969 matches
Mail list logo
