On Mon, Aug 20, 2018 at 12:10:08PM -0700, Pandiyan, Dhinakaran wrote:
>
>
> On Mon, 2018-08-20 at 10:15 +0300, Jani Nikula wrote:
> > On Fri, 20 Jul 2018, Rodrigo Vivi wrote:
> > > Instead of using a backchannel if some dpcd read failed we
> > > can show that directly on debugfs output.
> > >
>
On Mon, 2018-08-20 at 10:15 +0300, Jani Nikula wrote:
> On Fri, 20 Jul 2018, Rodrigo Vivi wrote:
> > Instead of using a backchannel if some dpcd read failed we
> > can show that directly on debugfs output.
> >
> > We are not returning an error because we might still want
> > to know if sub-sequ
On Fri, 20 Jul 2018, Rodrigo Vivi wrote:
> Instead of using a backchannel if some dpcd read failed we
> can show that directly on debugfs output.
>
> We are not returning an error because we might still want
> to know if sub-sequent reads works, but we shouldn't
> need to check 2 places to see why
Quoting Rodrigo Vivi (2018-07-20 18:41:10)
> Instead of using a backchannel if some dpcd read failed we
> can show that directly on debugfs output.
>
> We are not returning an error because we might still want
> to know if sub-sequent reads works, but we shouldn't
> need to check 2 places to see w
On Fri, 2018-07-20 at 10:41 -0700, Rodrigo Vivi wrote:
> Instead of using a backchannel if some dpcd read failed we
> can show that directly on debugfs output.
>
> We are not returning an error because we might still want
> to know if sub-sequent reads works,
We can print partial ( and successful
Instead of using a backchannel if some dpcd read failed we
can show that directly on debugfs output.
We are not returning an error because we might still want
to know if sub-sequent reads works, but we shouldn't
need to check 2 places to see why reg is not on the list.
Cc: Jani Nikula
Cc: Dhinak
