linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ShiHao <i.shihao.999@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	skhan@linuxfoundation.org, stern@rowland.harvard.edu
Subject: Re: [PATCH v2] usb: implement proper subclass protocol translation
Date: Sun, 12 Oct 2025 10:52:28 +0530	[thread overview]
Message-ID: <aOs7FNie4boeW-vw@fedora> (raw)
In-Reply-To: <3b6a43c5-6724-4940-b5b2-cadb5ebbb26d@rowland.harvard.edu>

 
> I'm sorry that you went through all this work, but it turns out that 
> this is almost totally unnecessary.  I should have realized this 
> earlier, but I didn't check the context of the patch until now.
> 
> At the place where you're changing the code, we know that srb->cmnd[0] 
> is always going to be REQUEST_SENSE = 0x03 (read the scsi_eh_prep_cmnd() 
> routine in drivers/scsi/scsi_error.c).  And we also know that 
> srb->cmnd_len will be set to 6, so there's no need to set it to 6 again.
> 
> All that this code needs to do is set srb->cmnd_len to 12 for the 
> special subclasses.  Nothing else.  I'm not even sure what the FIXME 
> is referring to.
> 
> Alan Stern
> 
> > -		/* FIXME: we must do the protocol translation here */
> > +		/* Handle usb subclass protocol translation */
> >  		if (us->subclass == USB_SC_RBC || us->subclass == USB_SC_SCSI ||
> > -				us->subclass == USB_SC_CYP_ATACB)
> > -			srb->cmd_len = 6;
> > -		else
> > +		    us->subclass == USB_SC_CYP_ATACB) {
> > +			/* Determine cmd_len based on scsi opcode group */
> > +			if (srb->cmnd[0] <= 0x1F)
> > +				srb->cmd_len = 6;
> > +			else if (srb->cmnd[0] <= 0x7F)
> > +				srb->cmd_len = 10;
> > +			else if (srb->cmnd[0] <= 0x9F)
> > +				srb->cmd_len = 16;
> > +			else if (srb->cmnd[0] <= 0xBF)
> > +				srb->cmd_len = 12;
> > +			else if (srb->cmnd[0] <= 0xDF)
> > +				srb->cmd_len = 16;
> > +			else
> > +				srb->cmd_len = 6;
> > +		} else {
> > +			/* Use fixed value for non-legacy subclasses */
> >  			srb->cmd_len = 12;
> > +		}

Hi alan ,

Well alan thanks for the review . Thank you so much for 
giving your percious time to this matter . I am just a newbie
in the kernel and i was just trying to learn things just to be a
kernel hacker your review has taught me how to submit a good 
commit and write code that is acceptable to the kernel .Thanks 
both greg  and you for reviewing my work . Thank you so much 
looking forward to submit  bug fixes :) . 


thanks 
shihao

      reply	other threads:[~2025-10-12  5:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-11  9:39 [PATCH v2] usb: implement proper subclass protocol translation Shi Hao
2025-10-11 17:05 ` Alan Stern
2025-10-12  5:22   ` ShiHao [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aOs7FNie4boeW-vw@fedora \
    --to=i.shihao.999@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).