Hi Marco,
m.fel...@pengutronix.de wrote on Thu, 18 Jul 2024 11:17:53 +0200:
> Hi Miquel,
>
> On 24-07-17, Miquel Raynal wrote:
> > Hi Marco,
> >
> > > > > > Overall I think the idea of getting rid of these misc/ drivers is
> > > > > > goes
> > > > > > into the right direction, but registerin
Hi Miquel,
On 24-07-17, Miquel Raynal wrote:
> Hi Marco,
>
> > > > > Overall I think the idea of getting rid of these misc/ drivers is goes
> > > > > into the right direction, but registering directly into NVMEM makes
> > > > > more sense IMO.
> > > >
> > > > So you propose to have two place
Hi Marco,
> > > > Overall I think the idea of getting rid of these misc/ drivers is goes
> > > > into the right direction, but registering directly into NVMEM makes
> > > > more sense IMO.
> > >
> > > So you propose to have two places for the partition handling (one for
> > > MTD and one for
On 24-07-09, Miquel Raynal wrote:
> Hi Marco,
>
> > > > > >> I also found a thread from 2013 by Maxime Ripard (+Cc) suggesting
> > > > > >> adding
> > > > > >> EEPROMs to MTD [1]. The main purpose would have been unifying the
> > > > > >> EEPROM
> > > > > >> drivers under a single interface. I a
Hi Marco,
> > > > >> I also found a thread from 2013 by Maxime Ripard (+Cc) suggesting
> > > > >> adding
> > > > >> EEPROMs to MTD [1]. The main purpose would have been unifying the
> > > > >> EEPROM
> > > > >> drivers under a single interface. I am not sure what came of it
> > > > >> though,
>
Hi Miquel,
On 24-07-08, Miquel Raynal wrote:
> Hi,
>
> > > >> >> Port the current misc/eeprom/at24.c driver to the MTD framework
> > > >> >> since
> > > >> >> EEPROMs are memory-technology devices and the framework already
> > > >> >> supports
> > > >> >
> > > >> > I was under the impression
Hi,
> > >> >> Port the current misc/eeprom/at24.c driver to the MTD framework since
> > >> >> EEPROMs are memory-technology devices and the framework already
> > >> >> supports
> > >> >
> > >> > I was under the impression that MTD devices are tightly coupled by
> > >> > erase
> > >> > blocks.
On Tue, Jul 02 2024, Maxime Ripard wrote:
> On Tue, Jul 02, 2024 at 03:41:52PM GMT, Pratyush Yadav wrote:
>> On Mon, Jul 01 2024, Tudor Ambarus wrote:
>>
>> > On 7/1/24 2:53 PM, Marco Felsch wrote:
>> >> EEPROMs can become quite large nowadays (>=64K). Exposing such devices
>> >> as single device
On Mon, Jul 01 2024, Tudor Ambarus wrote:
> On 7/1/24 2:53 PM, Marco Felsch wrote:
>> EEPROMs can become quite large nowadays (>=64K). Exposing such devices
>> as single device isn't always sufficient. There may be partitions which
>> require different access permissions. Also write access always
On Tue, Jul 02, 2024 at 04:15:20PM GMT, Pratyush Yadav wrote:
> On Tue, Jul 02 2024, Maxime Ripard wrote:
>
> > On Tue, Jul 02, 2024 at 03:41:52PM GMT, Pratyush Yadav wrote:
> >> On Mon, Jul 01 2024, Tudor Ambarus wrote:
> >>
> >> > On 7/1/24 2:53 PM, Marco Felsch wrote:
> >> >> EEPROMs can becom
On Tue, Jul 02, 2024 at 03:41:52PM GMT, Pratyush Yadav wrote:
> On Mon, Jul 01 2024, Tudor Ambarus wrote:
>
> > On 7/1/24 2:53 PM, Marco Felsch wrote:
> >> EEPROMs can become quite large nowadays (>=64K). Exposing such devices
> >> as single device isn't always sufficient. There may be partitions
On 7/1/24 2:53 PM, Marco Felsch wrote:
> EEPROMs can become quite large nowadays (>=64K). Exposing such devices
> as single device isn't always sufficient. There may be partitions which
> require different access permissions. Also write access always need to
> to verify the offset.
>
> Port the
At the moment there are three ways to access EEPROM content from
user-space:
1st) via the single nvmem device (rw)
2nd) via the single 'eeprom' device (rw)
3th) via nvmem-cells (r)
EEPROMs can become quite large nowadays (>=64K). Exposing such devices
as single device isn't always sufficien
13 matches
Mail list logo
