在 2021/10/26 下午2:10, Greg KH 写道:
On Tue, Oct 26, 2021 at 02:02:21PM +0800, Xianting Tian wrote:
在 2021/10/26 下午1:10, Jiri Slaby 写道:
On 15. 10. 21, 4:46, Xianting Tian wrote:
@@ -151,9 +142,11 @@ static uint32_t vtermnos[MAX_NR_HVC_CONSOLES] =
static void hvc_console_print(struct console *co, const char *b,
unsigned count)
{
- char c[N_OUTBUF] __ALIGNED__;
+ char *c;
unsigned i = 0, n = 0;
int r, donecr = 0, index = co->index;
+ unsigned long flags;
+ struct hvc_struct *hp;
/* Console access attempt outside of acceptable console
range. */
if (index >= MAX_NR_HVC_CONSOLES)
@@ -163,6 +156,13 @@ static void hvc_console_print(struct console
*co, const char *b,
if (vtermnos[index] == -1)
return;
+ hp = cons_hvcs[index];
+ if (!hp)
+ return;
You effectively make the console unusable until someone calls
hvc_alloc() for this device, correct? This doesn't look right. Neither
you describe this change of behaviour in the commit log.
I mentioned such info in the commit log:
'Introduce another array(cons_hvcs[]) for hvc pointers next to the
cons_ops[] and vtermnos[] arrays. With the array, we can easily find
hvc's cons_outbuf and its lock.'
After you pointed it out, I just found what you said make sense, I checked the
code hvc_console_print() can support print before hvc_alloc() is called when
someone use hvc_instantiate() for an early console discovery method.
I send a patch to fix the issue? or these serial pathches reverted fisrtly
then I resend new version patches? thanks
Let me revert these now and you can send an updated version.
OK, thanks.
thanks,
greg k-h
