Hi Aarya,
Thank you for contributing to flashrom. The merge of a patch sometimes
needs just time, even if it has +2.
The topic "fixing endianness issues" consists of tasks to rewrite code
that assumes a specific endianness. For example, the flashrom fmap
parser just maps packed c structs onto
Hi Aarya,
Thank you for contributing to flashrom. The merge of a patch sometimes
needs just time, even if it has +2.
The topic "fixing endianness issues" consists of tasks to rewrite code
that assumes a specific endianness. For example, the flashrom fmap
parser just maps packed c structs onto
I agree with Tim and will try to provide more requested information and
testing with those CLs.
> Only your reasoning "maintain the code symmetry" is not enough to justify
changes.
Kindly ignore my #2 comment, re-reading it doesn't make sense to me :) to
maintain the symmetry is the real reason
Hi Tim,
On 17.03.22 17:54, Tim Wawrzynczak wrote:
> On Thu, Mar 17, 2022 at 10:35 AM Nico Huber wrote:
>> I'm sorry if this affects your work, but we have very bad experience
>> with unnecessary code changes by CrOS developers. Currently `sb600spi`
>> (the equivalent to `ichspi` for AMD
On Thu, Mar 17, 2022 at 10:35 AM Nico Huber wrote:
> On 17.03.22 15:35, Subrata Banik wrote:
> > On Thu, Mar 17, 2022 at 6:08 PM Nico Huber wrote:
> >> On 16.03.22 17:19, Subrata Banik wrote:
> >>> The reason for this refactoring of HW sequencing SPI driver code are:
> >>> 1. We (Chrome OS
HI Nico,
Thanks for your email.
Please find my response below.
Thanks,
Subrata
On Thu, Mar 17, 2022 at 6:08 PM Nico Huber wrote:
> Hi Subrata,
>
> On 16.03.22 17:19, Subrata Banik wrote:
> > Hope you are doing well.
> > I would like bring this activity in your notice
> >
On 17.03.22 15:35, Subrata Banik wrote:
> On Thu, Mar 17, 2022 at 6:08 PM Nico Huber wrote:
>> On 16.03.22 17:19, Subrata Banik wrote:
>>> The reason for this refactoring of HW sequencing SPI driver code are:
>>> 1. We (Chrome OS team) recently ran into a firmware update issue on
>>> dogfooders
On 13.03.22 16:28, Nico Huber wrote:
> On 13.03.22 08:28, Anastasia Klimchuk wrote:
>>> I suggest that we freeze the master branch for everything that is neither
>>> a fix nor on the list (or a similar case that I missed)
>>
>> But how can we freeze master… that would mean no one can do any work?
Hi Anastasia,
On 17.03.22 12:32, Anastasia Klimchuk wrote:
>> For example, the flashrom project doesn't require that all comments
>> be resolved before merge. That can be enabled if you'd like, but currently
>> it isn't.
>
> Oh this explains! I was wondering where those “patches merged with
>
Hi Subrata,
On 16.03.22 17:19, Subrata Banik wrote:
> Hope you are doing well.
> I would like bring this activity in your notice
> https://review.coreboot.org/q/topic:PCH_HW_SEQ_Cleanup and seek help to
> review the code.
thank you for bringing this to the mailing list. Not only but also
because
“For example, the flashrom project doesn't require that all comments
be resolved before merge. That can be enabled if you'd like, but currently
it
isn't.”
Oh this explains! I was wondering where those “patches merged with
unresolved comments” are coming from. I am 100% voting for this setting to
Hello Team,
Hope you are doing well.
I would like bring this activity in your notice
https://review.coreboot.org/q/topic:PCH_HW_SEQ_Cleanup and seek help to
review the code.
The reason for this refactoring of HW sequencing SPI driver code are:
1. We (Chrome OS team) recently ran into a firmware
12 matches
Mail list logo
