On Sun, Aug 30, 2020 at 12:24 AM Mark Cave-Ayland
wrote:
>
> On 30/08/2020 07:49, Nathan Chancellor wrote:
>
> > Unfortunately, it does not. I applied it on top of latest
> > git (ac8b279f13865d1a4f1958d3bf34240c1c3af90d) and I can still
> > reproduce my failure. Is it possible that type of fix
On Sun, Aug 30, 2020 at 12:43 AM Nathan Chancellor
wrote:
>
> On Sun, Aug 30, 2020 at 08:24:15AM +0100, Mark Cave-Ayland wrote:
> > On 30/08/2020 07:49, Nathan Chancellor wrote:
> >
> > > Unfortunately, it does not. I applied it on top of latest
> > > git
On Wed, Aug 26, 2020 at 10:32:16PM -0700, Nathan Chancellor wrote:
> Hi all,
>
> Sorry for the duplicate reply, my first one was rejected by a mailing
> list administrator for being too long so I resent it with the error logs
> as a link instead of inline.
>
> On Wed, Jun 10, 2020 at 09:47:49AM
On 30/08/2020 08:43, Nathan Chancellor wrote:
> On Sun, Aug 30, 2020 at 08:24:15AM +0100, Mark Cave-Ayland wrote:
>> On 30/08/2020 07:49, Nathan Chancellor wrote:
>>
>>> Unfortunately, it does not. I applied it on top of latest
>>> git (ac8b279f13865d1a4f1958d3bf34240c1c3af90d) and I can still
On Sun, Aug 30, 2020 at 08:24:15AM +0100, Mark Cave-Ayland wrote:
> On 30/08/2020 07:49, Nathan Chancellor wrote:
>
> > Unfortunately, it does not. I applied it on top of latest
> > git (ac8b279f13865d1a4f1958d3bf34240c1c3af90d) and I can still
> > reproduce my failure. Is it possible that type
On 30/08/2020 07:49, Nathan Chancellor wrote:
> Unfortunately, it does not. I applied it on top of latest
> git (ac8b279f13865d1a4f1958d3bf34240c1c3af90d) and I can still
> reproduce my failure. Is it possible that type of fix is needed
> in a RISC-V specific driver?
>
> Would you like me to
On Sun, Aug 30, 2020 at 02:20:38AM -0400, Michael S. Tsirkin wrote:
> On Wed, Aug 26, 2020 at 10:32:16PM -0700, Nathan Chancellor wrote:
> > Hi all,
> >
> > Sorry for the duplicate reply, my first one was rejected by a mailing
> > list administrator for being too long so I resent it with the
On Wed, Aug 26, 2020 at 10:32:16PM -0700, Nathan Chancellor wrote:
> Hi all,
>
> Sorry for the duplicate reply, my first one was rejected by a mailing
> list administrator for being too long so I resent it with the error logs
> as a link instead of inline.
>
> On Wed, Jun 10, 2020 at 09:47:49AM
On Thu, Aug 27, 2020 at 08:53:30AM -0700, Alistair Francis wrote:
> On Wed, Aug 26, 2020 at 11:26 PM Nathan Chancellor
> wrote:
> >
> > Hi all,
> >
> > Sorry for the duplicate reply, my first one was rejected by a mailing
> > list administrator for being too long so I resent it with the error
On Wed, Aug 26, 2020 at 11:26 PM Nathan Chancellor
wrote:
>
> Hi all,
>
> Sorry for the duplicate reply, my first one was rejected by a mailing
> list administrator for being too long so I resent it with the error logs
> as a link instead of inline.
>
> On Wed, Jun 10, 2020 at 09:47:49AM -0400,
On 10/06/20 15:47, Michael S. Tsirkin wrote:
> Memory API documentation documents valid .min_access_size and .max_access_size
> fields and explains that any access outside these boundaries is blocked.
>
> This is what devices seem to assume.
>
> However this is not what the implementation does:
Memory API documentation documents valid .min_access_size and .max_access_size
fields and explains that any access outside these boundaries is blocked.
This is what devices seem to assume.
However this is not what the implementation does: it simply
ignores the boundaries unless there's an
On Wed, Jun 10, 2020 at 09:47:52AM -0400, Michael S. Tsirkin wrote:
> Memory API documentation documents valid .min_access_size and .max_access_size
> fields and explains that any access outside these boundaries is blocked.
>
> This is what devices seem to assume.
>
> However this is not what
13 matches
Mail list logo
